Provides tools to interact with Canvas LMS, including courses, modules, files, pages, assignments, submissions, grades, announcements, upcoming deadlines, and syllabus.
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 show my upcoming deadlines for this 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.
MCP server that exposes Canvas LMS as tools — courses, modules, files, pages, assignments, submissions/grades, announcements, upcoming deadlines, and syllabus.
Designed to be consumed by Ada (chat tool loop / edge functions) and any other MCP client (Claude Desktop, Cursor, etc.).
cd mcps/canvas
npm install
npm run buildCreate .env (or pass through your MCP client config):
CANVAS_BASE_URL=https://canvas.asu.edu/api/v1
CANVAS_TOKEN=your_canvas_personal_access_tokenGenerate the token in Canvas: Account → Settings → New Access Token.
Related MCP server: Canvas LMS MCP Server
Stdio transport (default for MCP clients):
CANVAS_BASE_URL=... CANVAS_TOKEN=... node dist/index.jsTool | Purpose |
| Active enrollments with term + dates |
| Single course incl. syllabus body |
| Modules with items inlined |
| Items in one module |
| File info + download URL |
| Download file body as UTF-8 text (truncated) |
| Wiki pages |
| Assignments by due date |
| Current student's grades + late/missing |
| Announcements across courses |
| Upcoming events for the user |
| Syllabus HTML |
{
"mcpServers": {
"canvas": {
"command": "node",
"args": ["/absolute/path/to/ada/mcps/canvas/dist/index.js"],
"env": {
"CANVAS_BASE_URL": "https://canvas.asu.edu/api/v1",
"CANVAS_TOKEN": "..."
}
}
}
}src/worker.ts exposes the same toolset over HTTP for hosting on Cloudflare
Workers. Deploy with:
npx wrangler deploySet the secrets once via wrangler secret put:
echo "https://canvas.asu.edu/api/v1" | npx wrangler secret put CANVAS_BASE_URL
echo "your_canvas_token" | npx wrangler secret put CANVAS_TOKENThe Worker accepts JSON-RPC tools/list and tools/call POSTs.
Multi-tenant headers (override env per request — Ada uses these):
Authorization: Bearer <user's canvas PAT>
X-Canvas-Base-Url https://canvas.<institution>.edu/api/v1
X-Ada-Service-Key <ADA_SERVICE_KEY> # required when env.ADA_SERVICE_KEY is setWhen no headers are present, the worker falls back to the CANVAS_BASE_URL /
CANVAS_TOKEN secrets (single-tenant mode). Set ADA_SERVICE_KEY to gate
header-based requests behind a shared secret:
echo "$(openssl rand -hex 32)" | npx wrangler secret put ADA_SERVICE_KEYCanvas pagination is followed automatically via the Link header up to per-call caps.
get_file_text decodes as UTF-8; binary formats (PDF, DOCX) need upstream extraction.
Single-tenant by env var. For multi-user (Ada), spawn one process per user or swap stdio for an HTTP transport that accepts a per-request token.
Get full details for a single assignment, including HTML description.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| assignment_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions 'including HTML description' as a return characteristic, but lacks information on side effects, authentication, or errors. Limited transparency.
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 sentence, making it concise. However, it is too brief to be fully informative; it could include more detail without losing conciseness.
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 2 parameters and no output schema, but the description lacks context on return value structure, expected IDs, or error handling. The 'HTML description' note adds minor value.
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%, and the description adds no explanation of parameters (course_id, assignment_id). The agent must rely solely on property names, which are generic.
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 retrieves details for a single assignment, distinguishing it from sibling tools like list_assignments (which returns multiple). The phrase 'full details' is slightly vague but acceptable.
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 on when to use this tool versus alternatives (e.g., list_assignments) or conditions for use. The agent must infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single course by id, including syllabus body if available.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the burden of behavioral disclosure. It only mentions the return content (course and syllabus), but omits critical traits like read-only nature, error handling (e.g., course not found), or authentication requirements.
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, efficient sentence with no filler or redundancy. Every word contributes to the core meaning.
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 low coverage of schema descriptions and absence of annotations, the description is insufficient. It does not explain the return structure, potential absence of syllabus, or behavior in error conditions, leaving gaps for the agent.
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 0% parameter description coverage, yet the description adds no meaning beyond 'by id'. It does not clarify the anyOf type (string or number), expected format, or how the course_id is used.
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 action 'Get a single course by id' and adds the distinctive detail 'including syllabus body if available', which differentiates it from sibling tools like list_courses (multiple courses) and get_syllabus (syllabus only).
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 offers no guidance on when to use this tool versus alternatives such as get_syllabus or list_courses. It merely describes the function, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Canvas file metadata (display_name, content-type, size, download URL).
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it mention authentication requirements, error handling, or side effects. The statement is minimal.
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 sentence that is concise and front-loaded with the core purpose. However, it could be slightly more informative about the parameter without losing conciseness. 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?
Given the tool's simplicity (one parameter, no output schema), the description provides a basic idea of what is returned. It lists some metadata fields but does not mention the response format, error conditions, or what happens with invalid file IDs. Adequate but incomplete.
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 input schema has a single parameter (file_id) with 0% coverage in the schema description. The tool description provides no explanation of the parameter, its format, or usage. It adds no value beyond the parameter name.
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 begins with a clear verb 'Get' and specifies the resource 'Canvas file metadata'. It lists specific metadata fields (display_name, content-type, size, download URL), distinguishing it from siblings like get_file_text and get_assignment.
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 simply states what the tool does without any guidance on when to use it versus alternatives. No mention of prerequisites, when not to use it, or how it compares to related tools like get_file_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a Canvas file and return up to max_bytes of its body decoded as UTF-8 text. Best for plaintext/markdown/code/HTML; binary formats (PDF, DOCX) return raw bytes — extract text upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ||
| max_bytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses UTF-8 decoding and raw bytes for binary, but does not mention truncation behavior when max_bytes is exceeded, error handling, or authentication requirements.
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?
Two sentences, no redundancy, front-loaded with the core action. Every word adds value.
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?
No output schema, and the description omits return format details for binary files (whether raw bytes are returned as blob or base64). For a simple file download tool, it is adequate but not exhaustive.
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 descriptions are 0%, so the description must compensate. It explains max_bytes ('up to max_bytes') but not file_id format or acceptable values. Both parameters lack detailed semantic context.
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 downloads a Canvas file and returns its text up to max_bytes, decoding as UTF-8. It distinguishes from sibling tools like get_file_metadata by focusing on file content.
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 specifies best use for plaintext and binary limitations, advising upstream extraction for binary formats. While it doesn't explicitly name alternative tools, the guidance on when not to use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a wiki page's full body (HTML) by its url slug.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| page_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the return format (HTML full body) but omits details like error handling, required permissions, rate limits, or behavior on missing/invalid slugs. For a simple getter, this is minimally 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information (verb, resource, input). No unnecessary words or extraneous details.
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's simplicity (two required parameters, no output schema, straightforward fetch operation), the description covers the essential purpose and input. Lacks discussion of edge cases or return format details, but overall adequate for the complexity level.
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 coverage is 0%, meaning no parameter descriptions exist. The description only mentions 'url slug', loosely mapping to page_url, but does not explain course_id or provide any additional semantics for either parameter. The anyOf type for course_id is left 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 identifies the action (Get), the resource (wiki page's full body as HTML), and the input key (url slug). It distinguishes from sibling tools like list_pages which list pages, and other getters for different resources.
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 no guidance on when to use this tool versus alternatives (e.g., list_pages to find slugs, or other getters). It does not mention prerequisites, contexts, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the syllabus body (HTML) for a course.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as HTML format details, error handling, authentication requirements, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant information; every word contributes to the purpose.
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?
Adequate for a simple tool: states it returns HTML syllabus body. Lacks details on output format or error conditions, but the tool is straightforward.
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 coverage is 0%, and the description does not elaborate on the 'course_id' parameter beyond stating it is for a course. No additional meaning beyond the schema.
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 action 'Get' and the resource 'syllabus body (HTML)' with scope 'for a course'. It effectively distinguishes from sibling tools like get_page or get_course.
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 explicit guidance on when to use this tool versus alternatives like get_page or get_course. Usage is only implied through the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List announcements across one or more courses.
| Name | Required | Description | Default |
|---|---|---|---|
| course_ids | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'List announcements' without disclosing pagination, authentication needs, or if it includes past/future announcements. Minimal behavioral 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?
Single sentence, no redundancy. Could be slightly more detailed but is appropriately short.
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?
No output schema and no description of return format, pagination, or ordering. Incomplete for a list tool with two parameters and no annotations.
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% and the tool description does not explain the parameters (course_ids, limit). Agent must infer from schema alone, which lacks semantics.
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 verb 'List' and resource 'announcements' with scope 'across one or more courses', making it distinct from siblings like list_assignments or list_courses.
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 on when to use this tool versus alternatives (e.g., list_assignments). Lacks context for prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assignments for a course ordered by due date. Returns due_at, points_possible, description, submission types.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what is returned (due_at, points_possible, description, submission types) and that results are ordered by due date. However, it does not specify sort direction, pagination, authentication needs, or any side effects. With no annotations, the description carries the burden but only partially addresses behavior.
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 sentence that conveys the core functionality without redundancy. It is appropriately sized for the tool's purpose.
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 lack of an output schema, the description should more fully explain return values and behavior. It lists only a few fields (likely incomplete) and omits important details like pagination, error handling, or what happens if the course_id is invalid.
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% and the description adds no meaning for the parameters. It does not explain that course_id can be a string or number, nor what limit controls (e.g., max number of assignments returned).
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 verb 'List' and resource 'assignments for a course', and specifies ordering by due date. It is distinct from siblings like get_assignment (single) and list_courses (different resource).
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 on when to use this tool versus alternatives such as get_assignment or list_my_submissions. No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated student's courses. Defaults to active enrollments. Returns id, name, course_code, term, and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| enrollment_state | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the default enrollment state, the returned fields, and that the tool lists courses. However, it omits behavioral traits like pagination behavior, error conditions, authentication requirements, or whether the list is ordered. The limit parameter suggests pagination but is not explained.
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?
Two sentences covering the essential action, default behavior, and output fields. No wasted words. The most critical information is front-loaded. The description is appropriately sized for the tool's simplicity.
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?
Despite low complexity (2 optional params, no output schema, no annotations), the description lacks completeness. It does not cover parameter details, error scenarios, or differentiate from siblings like list_assignments which also have enrollment_state. The returned fields list is helpful but incomplete without output schema or example.
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 not explain either parameter: enrollment_state (only implied default of 'active' but not the possible enum values) and limit (no explanation of its effect or default). The description adds no meaning beyond what the schema structurally provides.
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 verb (List), resource (courses), and scope (authenticated student's). It adds specificity with 'Defaults to active enrollments' and mentions returned fields. This distinguishes it from sibling tools like get_course (single course) or list_assignments (different resource).
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 no guidance on when to use this tool versus alternatives such as get_course for a single course or other listing tools. It does not mention prerequisites, exclusions, or contextual cues for selection. The agent must infer usage from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List items in a specific module (files, pages, assignments, quizzes, links).
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| module_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as pagination, error handling, or effect on system. Only states the action without side-effect details.
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?
Single sentence with no redundant words, but could be more informative. Efficient but slightly under-specified given lack of other documentation.
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?
No output schema, no annotations, and minimal parameter details. Missing return format, pagination info, and error conditions. Incomplete for a tool that likely returns a list.
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%; description adds context about item types but does not explain parameters course_id, module_id, or limit beyond their names. Insufficient for aiding correct invocation.
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 verb 'List items in a specific module' and enumerates example item types (files, pages, assignments, quizzes, links), distinguishing it from sibling tools like list_modules.
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 explicit guidance on when to use this tool vs alternatives, no prerequisites or exclusions mentioned. Only implied by context that it's for listing items within a module.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List modules for a course, with their items inlined. Use to see the structure of a course's content.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions items are inlined, but does not disclose other behaviors such as pagination, return format, potential limits, or read-only nature. This is minimal transparency.
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 two sentences long, front-loads the action ('List modules for a course'), and contains no superfluous words. Every sentence 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?
Given the tool's simplicity (two parameters, no output schema, no annotations), the description covers the core purpose but omits details like the meaning of 'limit' and the structure of the returned data. It is adequate for basic use but incomplete for deeper understanding.
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 does not explain either parameter (course_id or limit). The input schema has 0% description coverage for its properties, and the description adds no meaning beyond the schema itself. For two parameters, this 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 the tool lists modules for a course with their items inlined, using a specific verb and resource. It distinguishes from sibling tool list_module_items by noting the inlining of items, 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?
The description provides some context ('Use to see the structure of a course's content') but does not explicitly state when to use this tool versus list_module_items or any other sibling. It implies usage but lacks clear when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the current student's submissions for a course, including grade, score, late/missing flags, and the linked assignment. Use to detect grade drops and missing work.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists included fields (grade, score, late/missing flags) but omits behavioral traits like authentication needs, pagination behavior (limit parameter hint not explained), or ordering. Averages out as 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and use case. No wasted words, though could combine sentences for tighter structure.
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?
Simple tool with 2 parameters and no output schema, but description lacks parameter details (especially limit) and does not describe the return format (list of objects). Insufficient for reliable 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 coverage is 0%, so description must explain parameters. It only implicitly mentions course_id ('for a course') but does not describe the limit parameter (e.g., what it controls, default value). No parameter semantics provided.
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 'List the current student's submissions for a course' with specific fields (grade, score, late/missing flags). Distinguishes from sibling tools like list_assignments by focusing on submissions and the current student.
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 says 'Use to detect grade drops and missing work' providing a use case, but does not mention when not to use it or contrast with alternatives like list_assignments or get_assignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List wiki pages for a course.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose pagination behavior (despite a 'limit' parameter), ordering, or whether the result is a flat list. Almost no behavioral 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 a single concise sentence, but it sacrifices necessary details. It could be expanded slightly to cover parameters and behavior without becoming verbose.
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?
With no output schema, no annotations, and minimal description, the agent lacks essential context for a list tool. Missing details on pagination, ordering, and response format.
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 coverage is 0%, and the description adds no information about the parameters 'course_id' or 'limit'. The agent must infer meaning from names alone.
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 verb 'List' and the resource 'wiki pages' for a course, distinguishing it from 'get_page' which retrieves a single page. However, it doesn't specify the type of list (e.g., all pages or filtered).
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 on when to use this tool vs alternatives like 'get_page' or 'list_modules'. No mention of prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the current user's upcoming events (assignments + calendar items) across all courses. Use for deadline-aware planning.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It confirms the operation is read-only implicitly (listing events), but does not disclose ordering, pagination, or scope limitations beyond 'across all courses'.
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?
Two concise sentences, front-loaded with purpose and usage context. 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?
Adequate for a parameterless tool; explains what is listed and provides usage guidance. Lacks details on output format but acceptable given no output schema.
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?
No parameters exist, meeting baseline of 4. Description adds meaning by specifying the content (assignments + calendar items), which is not inferable from the empty schema.
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 verb 'list' and resource 'upcoming events (assignments + calendar items)' with scope across all courses for the current user, distinguishing it from siblings like list_assignments which may not filter by upcoming.
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?
Provides a usage context ('deadline-aware planning') but does not explicitly state when to avoid or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the authenticated Canvas user (id, name, email). Useful for validating a PAT.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description implies a read operation by stating it returns user info. Could add 'read-only' but not critical given simplicity.
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?
Two sentences, zero wasted words, front-loaded with key information.
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?
No output schema, but description enumerates returned fields (id, name, email). Complete for a tool of this simplicity.
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?
No parameters exist, so no additional information needed. Baseline 4 applies.
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 returns the authenticated Canvas user's id, name, and email, which is distinct from any sibling tools that return data about courses, assignments, etc.
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 mentions usefulness for validating a PAT, providing a clear context for when to use. No explicit when-not, but no sibling alternatives exist.
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. Dates show when Glama detected each change.
v0.1.0get_assignmentget_courseget_file_metadataget_file_textget_pageget_syllabuslist_announcementslist_assignmentslist_courseslist_module_itemslist_moduleslist_my_submissionslist_pageslist_upcomingwhoamiEach tool targets a distinct resource (course, assignment, page, file, etc.) or operation (list vs. get), with clear boundaries. No two tools have overlapping purposes.
Most tools follow a consistent verb_noun pattern (get_*, list_*), but 'whoami' breaks the pattern. However, this is a common convention and does not cause confusion.
15 tools is well within the ideal range (3-15). Each tool serves a clear purpose for student interaction with Canvas, neither too many nor too few.
The tool set covers all essential student-facing operations: viewing courses, assignments, submissions, pages, modules, files, announcements, syllabus, and upcoming events. No obvious gaps given the read-only student role.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage your Canvas coursework with quick access to courses, assignments, and grades. Track upcomin…
Create, validate, edit, export (markdown/svg/png/mermaid), and search JSON Canvas files.
Connect your Moodle to AI assistants: courses, content, grading and reports from the chat.
Create, edit, translate, and export SCORM eLearning modules from a connected AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abhinav-ranish/Canvas-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
