canvas-mcp

by salvadoracuna

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
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. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
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. 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![canvas-mcp MCP server](https://glama.ai/mcp/servers/salvadoracuna/canvas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/salvadoracuna/canvas-mcp)

Score Badge

Copy to your README.md:

[![canvas-mcp MCP server](https://glama.ai/mcp/servers/salvadoracuna/canvas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/salvadoracuna/canvas-mcp)

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/salvadoracuna/canvas-mcp'

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