Provides tools for interacting with Canvas LMS, enabling users to list active courses, upcoming assignments, and recent announcements.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@canvas-mcp List my assignments due in the next week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes Canvas LMS data (courses, assignments, announcements) to any MCP-compatible client (Claude Desktop, Claude Code, etc.).
This repository ships with no credentials. There is no Canvas token and no email address anywhere in it. You supply your own token in a local
.envfile that is git-ignored and never leaves your machine. See Where your token goes.
uv (Python package manager)
A Canvas LMS account with an API token
Related MCP server: canvas-mcp
Log in to your school's Canvas site (for example https://canvas.fen.uchile.cl)
Go to Account → Settings → Approved Integrations
Click + New Access Token, give it a name, and copy the token
Where your token goes: in a file named exactly .env, in the root of this
project folder (right next to main.py). That file is listed in .gitignore,
so git will never commit or push it.
Copy the template:
cp .env.example .envThen open .env and fill in the blanks:
# Your Canvas instance URL -- change this to your school's Canvas address
CANVAS_URL=https://canvas.fen.uchile.cl
# Paste the token from step 1 here
CANVAS_API_TOKEN=
# Optional second account (use account="udd" in the tools). Leave blank if unused.
CANVAS_UDD_URL=
CANVAS_UDD_TOKEN=Only CANVAS_URL and CANVAS_API_TOKEN are required. The CANVAS_UDD_* pair is
for an optional second Canvas account; leave both blank if you only have one.
Never commit
.env, never paste your token into a chat, and never put it in a file that gets shared. It grants full access to your Canvas account. If it leaks, delete the token in Canvas (Account -> Settings -> Approved Integrations) and generate a new one.
uv syncuv run python main.pyThe server communicates over stdio, so it won't print anything until an MCP client connects.
Add the following to your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"canvas": {
"command": "uv",
"args": ["run", "--project", "/absolute/path/to/canvas-mcp", "python", "main.py"]
}
}
}Replace /absolute/path/to/canvas-mcp with the real path to this folder. Use
forward slashes / even on Windows.
No token goes in this file. It is read from your
.env(see Where your token goes) --python-dotenvloads it automatically.
Add the MCP server in your Claude Code settings or run:
claude mcp add canvas -- uv run --project /absolute/path/to/canvas-mcp python main.pyTool | Description |
| Lists all active enrolled courses |
| Lists upcoming assignments sorted by due date |
| Lists recent announcements per course |
canvas-mcp/
├── main.py # MCP server
├── .env # Your token lives here (git-ignored, never pushed)
├── .env.example # Template
├── pyproject.toml # Project metadata & dependencies
└── uv.lock # Locked dependency versionsList recent announcements for all active enrolled courses.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds scope (all active enrolled courses) and recency (recent announcements) but does not explicitly state read-only behavior, pagination, or what 'recent' means. It does not contradict any annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the purpose and scope, making it easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is minimal but incomplete. It omits explanation of the 'account' parameter, any ordering or pagination details, and the exact meaning of 'recent' or 'active enrolled courses'. While an output schema exists (so return format is covered), the description still leaves functional ambiguity, especially regarding parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameter. The only parameter 'account' is not explained at all; the description does not clarify how it affects the query or what values it accepts. This leaves the agent guessing about its role, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (list) and resource (announcements) with a defined scope (all active enrolled courses). It is distinct from siblings like get_course_discussions or get_course_pages, making it unambiguous which resource the agent is retrieving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys its purpose clearly but does not explicitly mention alternatives or when not to use it. However, given the sibling tool names, the agent can infer that this tool is for announcements specifically, and no other tool targets this resource. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming assignments across all active enrolled courses, sorted by due date.
Args: days_ahead: Number of days ahead to look for assignments (default: 30).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| days_ahead | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It mentions 'active enrolled courses' and sorting by due date, but does not state side effects, permissions, rate limits, pagination, or error behavior. For a read-only list, more context would be expected, but the description adds little beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the primary purpose. The args are listed clearly, though the account param is missing. It is concise without unnecessary fluff, but the structure could be improved to include all parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and days_ahead, but misses the account parameter and offers no usage guidance or behavioral context. With two parameters and an output schema, the description is incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'days_ahead' with a default, but completely omits the 'account' parameter. This leaves a parameter undocumented, creating a gap for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'List' with a clear resource 'upcoming assignments across all active enrolled courses' and adds the sorting criterion 'by due date'. This distinguishes it from sibling tools that target specific courses or different content types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The description does not mention that course-specific assignments are handled by other tools, nor does it state any conditions, exclusions, or prerequisites. The agent is left to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List discussion topics (not announcements) for a course.
Args: course_id: The numeric Canvas course ID (get it from get_courses).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation and makes the topic/announcement boundary explicit, which is good. However, it does not mention pagination, ordering, permission requirements, or other runtime behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one opening sentence stating the operation and scope, followed by a minimal Args block. Every sentence earns its place, and the most important disambiguation is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers the return shape, and the description handles the core purpose and course_id provenance. However, the undocumented account parameter and the lack of an explicit pointer to get_announcements for announcements leave some contextual gaps for a two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must document all parameters. It explains course_id as the numeric Canvas course ID and how to obtain it, but it completely omits the account parameter that appears in the schema with a default value. This leaves a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List discussion topics' for a course. It explicitly disambiguates from announcements, which clearly separates it from the sibling get_announcements tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by specifying 'for a course' and instructs the agent to get course_id from get_courses. It implicitly excludes announcements, but does not explicitly name get_announcements as the alternative, so the guidance is not fully complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in a Canvas course, optionally scoped to a folder path.
Args: course_id: The numeric Canvas course ID (get it from get_courses). folder_path: Subfolder path to list (e.g. "lecture slides"). Leave empty for root.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| course_id | Yes | ||
| folder_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries the full burden. It accurately describes the operation but does not disclose read-only nature, error behavior, or edge cases. It adds only basic functional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main purpose in the first sentence and parameters clearly listed. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return structure is defined externally. The description covers the core functionality and key parameters, but misses the account parameter and explicit usage guidance, making it slightly incomplete for full agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains course_id and folder_path with usage details and examples, adding meaning beyond the schema which has 0% coverage. However, it omits the account parameter entirely, leaving one of three parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List files in a Canvas course' with clear verb and resource, and mentions optional folder scoping. It does not explicitly differentiate from sibling tools like read_course_file, but the verb 'list' distinguishes it inherently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a helpful hint that course_id should come from get_courses, but does not give explicit when-to-use vs when-not-to-use guidance relative to siblings like read_course_file. Usage is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current user's grades for all assignments in a course.
Args: course_id: The numeric Canvas course ID (get it from get_courses).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It implies a read-only operation via 'Show', but says nothing about authentication requirements, pagination, empty-grade behavior, or what happens when the course doesn't exist. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence plus a compact docstring-style args block. Purpose is front-loaded and there is no wasted prose. Loses a point only because the args section is slightly redundant with the input-schema structure presented nearby.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. But with no annotations, an undocumented account parameter, and no behavioral detail (pagination/errors/empty results), the definition leaves an agent guessing on how to call it robustly. For a two-param read tool this is only partially adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does document course_id ('The numeric Canvas course ID (get it from get_courses)'), adding type and provenance beyond the schema. However, the account parameter (with a 'uchile' default) is never mentioned, leaving the agent to guess its meaning — a real gap given zero schema-level coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Show the current user's grades for all assignments in a course' — and adds the 'current user's' scope qualifier. It's clear and none of the sibling tools (get_courses, get_assignments, etc.) deal with grades, so it's easily distinguished. Minor deduction because it partially echoes the tool name without adding much beyond the scope qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'get it from get_courses' for acquiring course_id, which is a weak step hint rather than real when-to-use guidance. No alternatives are named, no exclusions given, and no context about when this tool is preferred over the many sibling course tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all modules and their items for a course.
Args: course_id: The numeric Canvas course ID (get it from get_courses).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read-only action through the verb 'List' and states the scope ('all modules and their items'), but it does not disclose potential behaviors like pagination, hidden content, or whether anything could be modified. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single purpose sentence and one argument line. The main function is front-loaded, and no filler exists. The minor typo 'get_c_courses' does not undermine the structural quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with an output schema available, so return values do not need to be explained. The required course_id is documented with a source, and the optional account is a minor omission. The lack of annotations slightly reduces completeness, but overall an agent has enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds real meaning for course_id by specifying it is numeric and telling the agent to obtain it from get_courses. The optional account parameter is left unexplained, but since it has a default and is not required, the critical parameter is well covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource 'modules and their items' for a course, which clearly distinguishes it from sibling tools like get_course_files or get_course_pages. However, it does not explicitly name an alternative or contrast itself with a similar tool, so it stops short of the highest rating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage pointer: the course_id should come from get_courses (written as get_c_courses). This is helpful for prerequisites but does not explicitly explain when to choose this tool over alternatives or when not to use it. Usage guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List wiki pages in a course, or fetch the body of a specific page.
Args: course_id: The numeric Canvas course ID (get it from get_courses). page_url: The URL slug of a specific page to read (e.g. "syllabus"). Leave empty to list all pages.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| page_url | No | ||
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It implicitly indicates a read operation ('list' and 'fetch'), but never explicitly states it is read-only, does not mention side effects, permissions, or pagination behavior. The two modes are described, but deeper behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single opening sentence states the purpose, followed by a clean Args section. It front-loads the core functionality and includes practical examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a simple tool, especially with an output schema present to define return format. Yet the unexplained 'account' parameter is a gap, and there is no mention of authentication or whether the operation is safe to retry. Given the lack of annotations, this leaves some ambiguity, so it does not fully cover the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for course_id (numeric, sourced from get_courses) and page_url (URL slug with example, and 'empty to list all'). However, it completely ignores the 'account' parameter, which appears in the schema with a default. Thus it covers two of three parameters, adding value but missing one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists wiki pages or fetches a specific page's body, with a specific verb and resource. It is distinct from siblings (assignments, files, modules) by the subject matter, though it never explicitly names an alternative. This is clear but not maximally differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter usage guidance (e.g., how to get course_id from get_courses, the meaning of page_url, and that an empty page_url lists all pages). However, it provides no guidance on when to choose this tool over alternatives, nor any exclusions or trade-offs. There is implied usage context but no explicit tool-selection direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List people enrolled in a course, optionally filtered by role.
Args: course_id: The numeric Canvas course ID (get it from get_courses). role: Filter by enrollment role. One of: StudentEnrollment, TeacherEnrollment, TaEnrollment, ObserverEnrollment, DesignerEnrollment. Leave empty for all.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| account | No | uchile | |
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only says 'List' (implying read-only) but does not state it explicitly, nor mention pagination, response format, or any side effects. Additionally, the account parameter is undocumented in the description, creating a hidden behavioral aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description has a concise one-sentence summary followed by a structured argument list. It avoids redundancy and is well-organized, though the argument list could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations, the description is incomplete. It omits the account parameter, does not explicitly confirm the read-only nature, and provides no details on return structure (though an output schema exists). The lack of behavioral disclosure makes it insufficient for an agent to call it without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. It explains course_id (source from get_courses) and role (allowed enums and default behavior), which adds meaning. However, the account parameter is entirely omitted, leaving a third of the parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List people enrolled in a course, optionally filtered by role' – a specific verb and resource. It is distinct from siblings like get_assignments or get_announcements, which handle different entities, so an agent can immediately understand what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by instructing to obtain course_id from get_courses and explaining role filtering with allowed values. It does not explicitly exclude alternatives, but the tool's purpose is narrow enough that siblings are clearly different. No misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active enrolled courses from Canvas LMS.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a read-only listing operation scoped to 'active' and 'enrolled' courses, which is useful. However, it does not mention pagination, ordering, or how the optional account parameter affects results—though the output schema likely covers return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, with no filler or repetition. Every word contributes meaning, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list operation, and the output schema presumably documents the return payload. However, it leaves the 'account' parameter unexplained and offers no guidance on when this tool is preferable to or distinct from the many sibling tools, so some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'account', with a default of 'uchile' and no description. The tool description does not mention or explain this parameter at all, and schema description coverage is 0%. Since the description must compensate for undocumented parameters, its failure to address 'account' leaves the agent guessing about its meaning and allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all active enrolled courses from Canvas LMS'), clearly distinguishing it from sibling tools that operate on specific course content like assignments, announcements, or files. This leaves no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to call when you need the list of courses a user is actively enrolled in, which is a natural precursor to course-specific tools. However, it provides no explicit when-to-use guidance, exclusions, or contrast with siblings like get_assignments or get_course_pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download and read the text content of a file from a Canvas course. Supports PDF (with OCR fallback for scanned PDFs), Word (.docx), PowerPoint (.pptx), Excel (.xlsx), and plain-text/HTML files. Use get_course_files to find file IDs.
Args: course_id: The numeric Canvas course ID. file_id: The numeric Canvas file ID.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | uchile | |
| file_id | Yes | ||
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses OCR fallback for scanned PDFs and enumerates supported formats, which are useful behavioral traits. However, it doesn't explicitly state that this is a read-only operation, nor does it mention any limitations (e.g., file size limits, timeout, or error behavior). The read-only nature is implied but not stated, and no further side effects or constraints are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with the core purpose and supported formats in the first two sentences, followed by a compact Args list. The structure is clean and front-loaded. It could be slightly more organized (e.g., using bullet points for args), but it remains clear and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (multi-format support with OCR fallback) and the existence of an output schema, the description covers the main function and key formats. However, the complete omission of the account parameter is a significant gap, as is the lack of any mention of error handling or unsupported formats. The output schema may cover return values, but the description does not explain the context of file access (e.g., permissions or ownership), which could be relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it barely does. It repeats that course_id and file_id are numeric, which the schema already states via integer type, and it omits the account parameter entirely. The account parameter has a default, but its purpose or when to override it is not explained. The description fails to clarify the role of account, leaving a parameter undocumented in any meaningful way.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool downloads and reads text content from a Canvas file, with a specific resource (file from course) and verb. It distinguishes from siblings like get_course_files (which lists files) by focusing on reading content. The supported formats add specificity, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to use get_course_files to find file IDs, providing a clear prerequisite. It also lists which file formats are supported, implying when the tool is applicable. While it doesn't state when not to use it, there is no obvious alternative for reading file content, and the pointer to get_course_files is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_announcementsget_assignmentsget_course_discussionsget_course_filesget_course_gradesget_course_modulesget_course_pagesget_course_peopleget_coursesread_course_fileScored across 10 tools
Every tool targets a distinct resource and action. get_courses vs get_assignments vs get_announcements are clearly separated, and even similar tools like get_course_files (listing) and read_course_file (reading content) are unambiguous.
All tools follow a verb_noun pattern with 'get_' prefix, except read_course_file which uses 'read_'. This is a minor deviation but the rest are consistent, and the naming is predictable overall.
The 10 tools are well-scoped for a read-only Canvas LMS server. They cover the main course-related resources without being excessive, fitting comfortably within the ideal 3-15 range.
For a read-only surface, it covers the major resources: courses, assignments, announcements, files, modules, people, grades, discussions, and pages. Minor gaps exist (e.g., no single-course detail endpoint, no calendar events), but the core read workflows are covered without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
MCP adapter for the Paxaver school community platform. Streamable HTTP, OAuth 2.1, capability auth.
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
Remote MCP server for training, nutrition, wellness, and performance data with OAuth 2.0.
