Provides read-only access to Canvas LMS data including courses, assignments, grades, deadlines, files, rubrics, and submission feedback.
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 Server what's due 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.
A read-only Model Context Protocol server that gives an AI assistant full structured access to a Canvas LMS account — courses, assignments, grades, deadlines, files, rubrics, and submission feedback.
Instead of opening Canvas and clicking through six courses to figure out what's due, you ask: "what's due this week and what am I behind on?" and get an answer grounded in live data.
Canvas holds everything a student needs, spread across a UI that requires a lot of navigation to answer simple cross-course questions. "What's due in the next two weeks?" means visiting every course individually. There's an API, but it's awkward in ways that make naive integrations break:
Array parameters require bracket notation (include[]=total_scores), silently ignored otherwise
Pagination is driven entirely by Link headers — page-number guessing skips and duplicates records
Rate limits are enforced by a leaky-bucket quota exposed in response headers
Every text field is HTML, not plain text — unusable in a model context without cleaning
Enrollments span all past semesters, so "my courses" needs term-aware filtering
This server absorbs that complexity and exposes 23 clean tools.
Related MCP server: Canvas MCP Server
Two-phase loading. List endpoints return lightweight representations; full content is fetched on demand. Pulling every assignment description across six courses wastes an enormous amount of context for a question like "what's due Friday." List calls stay cheap, detail calls are explicit.
Link-header pagination. paginate() is an async generator that follows Link: rel="next" until exhausted or a caller-supplied limit is hit, yielding items individually so callers can stop early without over-fetching.
Rate-limit awareness, not just retry. The client reads X-Rate-Limit-Remaining and pre-emptively backs off when the quota drops below 50, in addition to exponential backoff on 429s. Reacting only to 429s means you've already been throttled.
Current-semester detection. _is_current_course() filters enrollments by term dates so tools operate on the active semester without the user passing IDs around.
HTML stripping at the boundary. Canvas returns HTML in every description, announcement, and discussion body. It's converted to plain text before reaching the model — script and style blocks removed, <br> mapped to newlines.
Singleton HTTP client. One httpx.AsyncClient with connection pooling for the process lifetime, rather than a new connection per tool call.
Read-only by design. No tool mutates Canvas state. An LLM cannot submit an assignment, post to a discussion, or alter a grade — the blast radius of a bad generation is zero.
Core — get_my_courses, get_todo, get_all_upcoming(days), get_all_grades
Course content — get_course, get_assignments, get_assignment, get_announcements, get_announcement, get_discussions, get_discussion, get_quizzes, get_quiz, get_calendar_events, get_rubrics, get_rubric
Files & modules — get_files, get_file, get_modules, get_module_items, get_page
Submissions — get_submission (includes instructor feedback and rubric assessment)
Aggregator — get_full_course_context (entire course in one call, for deep questions)
uv sync
cp .env.example .env # then add your tokenGenerate a token at Canvas → Account → Settings → New Access Token.
CANVAS_TOKEN=your_canvas_api_token_here
CANVAS_BASE_URL=https://your-institution.instructure.comRegister with an MCP client (Claude Code shown):
claude mcp add canvas -- uv --directory /path/to/canvas-mcp run server.pyPython 3.11+ · mcp · httpx (async) · python-dotenv · typed dataclass models throughout
Your access token carries your full Canvas privileges. It lives in .env, which is gitignored — don't commit it, and revoke it from Canvas settings if it's ever exposed.
Built against the Canvas API as deployed by Northeastern University. Institutions can disable endpoints, so tool availability may vary.
Get grades for all active courses.
Returns: {"grades": [{course_id, course_name, current_score, current_grade}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return structure (grades with fields and count) but does not explain what 'active courses' means, whether it's user-specific, or any rate limits/authorization requirements. Partial transparency, lacking depth.
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 efficient sentences: one for purpose, one with return format. No filler, front-loaded. 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?
For a zero-parameter read-only tool, the description adequately explains functionality and output. However, it could be more precise about scope (e.g., 'all active courses for the current user') and any missing edge cases like empty grades. Still fairly complete given sibling tool 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?
No parameters exist, so the schema covers 100%. The description adds no parameter meaning beyond schema, but the baseline for zero parameters is 4. It does not need to clarify parameters.
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 'Get' and resource 'grades for all active courses'. It distinguishes from siblings like 'get_my_courses' (which lists courses) and 'get_course' (details of a specific course). The purpose is immediately clear.
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_course' for a single course or 'get_my_courses' for course list. No when-not-to-use or context provided. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming assignments across all active courses.
Args: days: How many days ahead to look (default 14)
Returns: {"assignments": [{id, name, due_at, course_name, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions 'active courses' but does not define 'active', nor does it indicate whether the operation is read-only or has side effects. The return format is helpful, but key behavioral context is missing.
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?
Extremely concise with two sentences plus structured Args/Returns. No unnecessary words; every element 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?
For a simple tool with one parameter and no annotations, the description adequately covers core functionality, parameter, and return format. Could improve by explaining 'active courses' and error conditions, but overall sufficient.
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%, but the description's Args section adds meaning beyond the schema: 'How many days ahead to look (default 14)'. This compensates well for the single parameter's lack of schema description.
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?
Clearly states 'Get upcoming assignments across all active courses', providing specific verb and resource scope. Distinguishes from siblings like get_assignments (course-specific) and get_todo (broader).
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?
Implies usage for retrieving assignments across all courses via the phrase 'across all active courses', but does not explicitly state when to use versus alternatives like get_assignments or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single announcement with full body.
Args: course_id: Canvas course ID announcement_id: Canvas announcement (discussion topic) ID
Returns: {id, title, message, posted_at, author, attachments}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| announcement_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the operation 'Get' (implying read-only) and lists return fields, but it does not address idempotency, error handling, required permissions, or performance characteristics. For a tool with no annotations, this is insufficient.
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 (three sections: purpose, args, returns) with no extraneous words. It front-loads the purpose and organizes details clearly. Every sentence 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?
Given the low complexity (2 params, no nested objects, no output schema), the description covers the essential details: tool purpose, parameter semantics, and return structure. It lacks error handling or edge case info, but for a simple retrieval tool, it is largely complete.
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 0% description coverage, so the description must compensate. It adds meaning by labeling both parameters ('Canvas course ID' and 'Canvas announcement (discussion topic) ID'), which clarifies their purpose beyond type hints. However, it does not detail sources or valid ranges, so contribution is modest.
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 purpose: 'Get a single announcement with full body.' It specifies the verb 'Get' and resource 'announcement', and distinguishes this tool from its sibling 'get_announcements' by emphasizing 'single'. The return fields are listed, providing additional clarity.
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 does not explicitly state when to use this tool versus alternatives. While the sibling 'get_announcements' implies a plural listing, there is no direct guidance on selection criteria or exclusions. Usage is inferred from context but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get announcements for a course (list view).
Args: course_id: Canvas course ID
Returns: {"announcements": [{id, title, posted_at, author}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It only states it returns a list but omits details on pagination, ordering, permissions, or whether inactive announcements are included.
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 (three short sections), front-loads the purpose, and has no redundant sentences. Could be slightly more structured but is effective.
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?
Provides basic purpose and return structure, but lacks behavioral details (e.g., pagination, ordering) that would be necessary for complete autonomous usage given a single parameter and 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?
Schema description coverage is 0%. The description adds 'Canvas course ID' but no format, example, or constraints beyond the schema's integer type. Fails to compensate for low 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 clearly states the verb 'Get' and the resource 'announcements for a course' with the qualifier '(list view)', distinguishing it from the sibling tool 'get_announcement' that likely returns a single item.
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 like 'get_discussions' or 'get_announcement'. The description does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single assignment with full description and attachments.
Args: course_id: Canvas course ID assignment_id: Canvas assignment ID
Returns: {id, name, description, due_at, points_possible, submission_types, attachments, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| assignment_id | 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 includes a representative return structure ({id, name, description, due_at, ...}) indicating a read operation, but lacks disclosure of authentication needs, error handling, or rate limits.
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 front-loaded with a clear one-line purpose, followed by Args and Returns sections. It is efficient and scannable, though the Returns section partly repeats the initial claim of 'full description and attachments'.
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 2-parameter read tool, the description provides param descriptions and a return field sample. Given no output schema or annotations, this is adequate for an agent to understand usage, though error cases and performance implications are omitted.
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%, but the description explicitly defines both parameters ('course_id: Canvas course ID', 'assignment_id: Canvas assignment ID'), adding meaning beyond the schema's type and title. This compensates for the lack of schema descriptions, though more detail on expected formats could be given.
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 'Get a single assignment with full description and attachments,' specifying the action (get), resource (assignment), and scope (single). This distinguishes it from the sibling 'get_assignments' which would list multiple assignments.
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 implicitly indicates use when needing a specific assignment by ID, but does not explicitly state when to use this tool versus alternatives like 'get_assignments' or 'get_submission'. No when-not or contextual cues are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all assignments for a course.
Args: course_id: Canvas course ID
Returns: {"assignments": [{id, name, due_at, points_possible, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that the tool returns 'assignments' and 'count', and shows the fields in the return format. However, it omits details like pagination, ordering, whether it returns only published assignments, or required permissions. The behavioral info is 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 concise, using a docstring format with 'Args' and 'Returns' sections. It front-loads the main purpose. Every sentence contributes useful information, though the formatting labels are slightly redundant.
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 a simple tool with one parameter and no output schema, the description covers the basic purpose and return structure. However, it lacks details on pagination, filtering, or permissions. Compared to siblings with similar tool patterns, it is not fully complete but covers the essentials.
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 only has a type and title for 'course_id' (integer), and schema coverage is 0%. The description adds meaning by specifying it is a 'Canvas course ID' and that it is required, which is useful context 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 'Get all assignments for a course' with a specific verb and resource. It also mentions the 'course_id' argument, making the tool's purpose unambiguous. It distinguishes from siblings like 'get_assignment' (singular) and other resource-specific get tools.
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 provided on when to use this tool vs. alternatives. There are many sibling tools for different resources (e.g., get_course, get_announcements), but no explicit context or exclusions are given. The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get calendar events for a course.
Args: course_id: Canvas course ID
Returns: {"events": [{id, title, start_at, end_at, description, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should explicitly state that this is a read-only operation, but it does not. It only describes the return format, omitting behavioral traits like side effects, idempotency, or permissions needed.
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 short and to the point, with structured Args and Returns sections. The JSON snippet is somewhat verbose but useful. No extraneous content.
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 no output schema, the description partially explains the return structure but omits field details and assumptions (e.g., time range filtering). The tool's position among many sibling tools calls for clearer context, which 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 single parameter 'course_id' is described as 'Canvas course ID', which adds modest meaning beyond the schema title 'Course Id'. However, with 0% schema description coverage, the description does not fully compensate (e.g., no hint on how to obtain the ID).
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 it retrieves calendar events for a course, which is a specific verb and resource. It distinguishes from sibling tools focused on other resources like assignments or announcements.
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 provided on when to use this tool vs alternatives (e.g., get_todo, get_all_upcoming). There is no mention of when not to use it or prerequisites like requiring a valid course_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full course details including syllabus.
Args: course_id: Canvas course ID
Returns: {id, name, code, term, syllabus, description, start_at, end_at, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | 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 does not state that the tool is read-only, lacks side effects, or any authentication requirements. The return format is implied but not explicitly defined.
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 with three short lines covering purpose, parameters, and return example. It front-loads the key action and resource.
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 retrieval tool with one parameter, the description is mostly complete, listing example return fields. However, it omits error handling (e.g., if course not found) and potential pagination or rate limits.
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 adds minimal value by restating 'course_id: Canvas course ID'. It does not provide format, validation, or constraints beyond the schema's type and requirement.
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 full course details including syllabus, distinguishing it from siblings like 'get_my_courses' (which lists courses) and 'get_full_course_context' (broader scope).
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_my_courses' or 'get_full_course_context'. There is no mention of prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single discussion topic with full message body.
Args: course_id: Canvas course ID discussion_id: Canvas discussion topic ID
Returns: {id, title, message, posted_at, author, attachments, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| discussion_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It mentions the return format and fields, but does not disclose potential errors, permissions, or rate limits. Acceptable for a basic read tool.
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 short with clear Args and Returns sections. No wasted words, though the format could be slightly more compact. Efficient for a simple tool.
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 low-complexity tool with 2 parameters and no output schema, the description covers purpose, parameters, and return fields. It omits error handling but is sufficient for an agent to invoke 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?
The schema has no descriptions, and the description adds some meaning by labeling parameters (e.g., 'course_id: Canvas course ID'). However, it does not elaborate beyond the names, leaving interpretation to the agent. Schema coverage is 0%, so description partially compensates.
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 'Get a single discussion topic with full message body', providing a specific verb and resource that distinguishes it from sibling tools like get_discussions (which lists topics).
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 lacks any guidance on when to use this tool versus alternatives, such as when to use get_discussions instead. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all discussion topics for a course.
Args: course_id: Canvas course ID
Returns: {"discussions": [{id, title, posted_at, author, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks behavioral traits like pagination, sorting, or permission requirements. Return format is hinted but not enough detail.
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?
Short and front-loaded with purpose, structured Args/Returns. No fluff.
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 list tool but lacks details on pagination, filtering, or common edge cases. Return format helps.
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%. Description only says 'course_id: Canvas course ID', adding minimal meaning beyond 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?
Clearly states 'Get all discussion topics for a course' with verb and resource. Distinguishes from sibling 'get_discussion' (singular) by context, but no explicit differentiation.
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, no when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get file metadata and download URL.
Args: file_id: Canvas file ID
Returns: {id, display_name, size, content_type, url, created_at, updated_at}
| 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 carries full burden. It does not explicitly state that the tool is read-only or non-destructive, only listing returned fields. This leaves uncertainty about behavior (e.g., side effects, authentication needs).
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: two sentences plus listed Args/Returns. Every word serves a purpose, and the purpose is front-loaded. No unnecessary 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?
For a simple tool (1 param, no output schema), the description adequately covers purpose, parameter, and return fields. However, it omits error scenarios, access requirements, and edge cases. The return format is described but not in full JSON schema detail.
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 (file_id) with no description; the description adds 'Canvas file ID', clarifying its meaning. With 0% schema coverage, this addition is helpful but minimal. No further details like constraints or expected format.
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 'Get' and the resource 'file metadata and download URL', indicating it retrieves information for a single file. It distinguishes itself from 'get_files' (plural) by implying singular retrieval via file_id, though it does not explicitly differentiate.
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 provided on when to use this tool versus alternatives (e.g., get_files for multiple files). The description lacks context on prerequisites, restrictions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files in a course.
Args: course_id: Canvas course ID
Returns: {"files": [{id, display_name, size, content_type, url}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It specifies the return format, which adds transparency, but lacks information on authentication, rate limits, or side effects. For a read-only listing tool, the return format is helpful but behavioral context 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?
Very concise, structured with Args and Returns sections, no wasted words. Every sentence 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?
Given no output schema, the description includes a return format, which is helpful. For a simple list tool, it covers the essentials. However, missing pagination or limits would be useful but not critical.
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%, but the description adds 'course_id: Canvas course ID', explaining the parameter's meaning beyond the schema's type-only definition. With only one parameter, this provides essential 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?
Description clearly states 'List all files in a course' with a specific verb and resource, distinguishing it from sibling tools like get_file (single file) and other list tools.
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., get_file for a single file). The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get EVERYTHING for a course in one call: details, syllabus, assignments, announcements, discussions, modules, files, and grades.
Args: course_id: Canvas course ID
Returns: {course, assignments, announcements, discussions, modules, files, grades}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses the return structure with keys like {course, assignments, ...}. However, it omits potential behavioral traits such as performance impact, permission requirements, or error handling for missing data.
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?
Highly concise with no wasted words. Structured Args/Returns section aids parsing. Every sentence 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?
Adequate for a single-parameter bulk retrieval tool, but lacks details on potential pagination, error handling, or behavior when sub-resources are empty. Could benefit from noting that this is a heavy composite call.
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?
Single parameter course_id is described as 'Canvas course ID', which adds minimal meaning beyond the schema property name. Schema coverage is 0%, so the description does not compensate with additional context like formatting or constraints.
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 it retrieves 'everything for a course in one call' and enumerates the specific components (details, syllabus, etc.). It distinguishes itself from sibling tools like get_course and get_assignments by being a comprehensive bulk endpoint.
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?
Implied usage is for fetching all course data at once, but no explicit when-to-use or when-to-avoid guidance. Sibling tools are listed but not referenced as alternatives for targeted queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get items within a module.
Args: course_id: Canvas course ID module_id: Canvas module ID
Returns: {"items": [{id, title, type, content_id, html_url, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| module_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Get items' and shows return format, but does not disclose pagination, sorting, or permission requirements. A simple read operation, but lacking behavioral 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?
The description is short and front-loaded with the main purpose. It includes Args/Returns in a structured format, which is efficient and organized, though could be slightly more concise.
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 simple tool (2 params, no output schema), the description covers basic functionality and return format. However, it lacks details on error handling, limits, or example usage, leaving gaps for an 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?
Schema description coverage is 0%, and the description adds only parameter names in a list. No additional meaning beyond what the schema provides (type and required). For two straightforward ids, this is minimal but sufficient.
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 'Get items within a module', specifying the verb and resource. It distinguishes from sibling tools like get_modules (which lists modules) and get_page (single page).
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 like get_full_course_context or get_page. The description simply states the action without context of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get module structure for a course.
Args: course_id: Canvas course ID
Returns: {"modules": [{id, name, position, items_count, state}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the return format (JSON with modules array and count), which is useful, but does not disclose any behavioral traits like permissions, side effects, or read-only nature beyond the implicit verb.
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, using a single line for purpose and a few lines for parameters and return. Every sentence is informative with 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?
For a simple getter tool with one parameter, the description adequately covers input and output. It lacks error information but is sufficient for agent selection and 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?
The description adds meaning by clarifying 'course_id' as 'Canvas course ID' and explicitly documents the return format. This adds value beyond the input schema, which only specifies type and required status.
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 'Get module structure for a course' with a specific verb and resource, distinguishing it from siblings like get_module_items and other course retrieval tools.
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 when or when-not to use the tool is given; usage is implied by the tool's name and purpose, but no alternatives or context exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current semester courses (auto-detected as active).
Returns: {"courses": [{id, name, code, term}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states auto-detection of active semester and includes the return format, but does not cover error conditions, authentication requirements, or whether it is read-only (though implied). It adds moderate 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 extremely concise, consisting of two sentences that front-load the core purpose and return format. Every sentence adds value without verbosity.
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 tool with no parameters and no output schema, the description is complete enough. It specifies the resource (courses), auto-detection, and return format. However, given the many sibling tools, a bit more context to differentiate could improve completeness.
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 tool has zero parameters and schema description coverage is 100%. Since there are no parameters to document, the description does not need to add parameter semantics. The baseline score for no parameters is 4.
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 current semester courses with auto-detection of active semester. The verb 'Get' and resource 'courses' are specific and distinct from siblings like 'get_course' (singular) and 'get_full_course_context' (full course context).
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 usage for current semester courses but does not explicitly state when to use this tool versus alternatives like 'get_course' or 'get_full_course_context'. No exclusions or 'when not to use' guidance is provided.
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 content with embedded file links.
Args: course_id: Canvas course ID page_url: Page URL slug (e.g., "syllabus" or "week-1-notes")
Returns: {title, body, created_at, updated_at}
| Name | Required | Description | Default |
|---|---|---|---|
| page_url | Yes | ||
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it returns content with embedded file links and gives return format. Lacks disclosure about read-only nature, permissions, 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?
Structured with Args and Returns sections, concise at 4 lines. However, Args section repeats parameter names from schema, but the descriptions are valuable.
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 specifies return shape {title, body, created_at, updated_at} and mentions embedded file links. Adequate for a simple GET tool with 2 parameters.
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%. The description adds crucial meaning for both parameters: course_id (Canvas course ID) and page_url (with examples like 'syllabus'), fully compensating for the bare 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?
Clearly states verb 'Get' and resource 'wiki page's content with embedded file links'. Differentiates from many other 'get' tools for specific 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?
No guidance on when to use this tool versus alternatives like get_file or get_course. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single quiz with full details.
Args: course_id: Canvas course ID quiz_id: Canvas quiz ID
Returns: {id, title, description, due_at, points_possible, time_limit, question_count, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| quiz_id | Yes | ||
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states returns full details with sample fields, but lacks info on permissions, error cases, or constraints beyond what's in the schema.
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-sentence description is efficient, front-loaded with purpose, and every sentence adds value without 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?
For a simple retrieval tool, description covers purpose, required params, and sample return fields; could mention error handling or that quiz must exist, but overall 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 coverage 0% so description must clarify parameters; it adds 'Canvas course ID' and 'Canvas quiz ID' which is minimal and does not elaborate on format or constraints.
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?
Clear verb 'get' with resource 'single quiz' and 'full details' distinguishes from sibling 'get_quizzes' which lists quizzes.
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?
Implied usage when specific quiz_id is known, but no explicit guidance on when to use versus get_quizzes or alternatives like get_assignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all quizzes for a course.
Args: course_id: Canvas course ID
Returns: {"quizzes": [{id, title, due_at, points_possible, time_limit, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation and returns a specific structure, but lacks details on authentication, pagination, or behavior beyond the basic retrieval.
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 short and front-loaded with the purpose. Args and returns are listed efficiently. Minor improvement could be clearer structure, but it is appropriately sized.
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 complexity (1 parameter, simple return), the description covers the basics. It provides return structure and parameter purpose. Lacks details on error cases or empty results, but adequate for a simple listing 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?
Schema coverage is 0%, and the description adds minimal meaning: 'course_id: Canvas course ID' explains the parameter's role but no format or constraints beyond the schema's integer type. Does not fully compensate for lack of schema descriptions.
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 'Get all quizzes for a course,' specifying the resource (quizzes) and action (get all). This distinguishes it from sibling tool 'get_quiz' which retrieves a single quiz.
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 like 'get_quiz'. The description implies it is for listing all quizzes but does not provide when-not or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single rubric with full criteria.
Args: course_id: Canvas course ID rubric_id: Canvas rubric ID
Returns: {id, title, points_possible, criteria: [{description, points, ratings}, ...]}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| rubric_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return format, adding transparency, but does not mention idempotency, authentication needs, rate limits, or error conditions. It 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: one sentence for purpose, then labeled Args and Returns sections. Every word adds value, with no redundancy. Well-structured for quick parsing.
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 read tool with two parameters and no output schema, the description fully covers purpose, parameters, and return format. No additional context is necessary given the tool's simplicity and the presence of sibling tools.
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 provides informal meanings ('Canvas course ID', 'Canvas rubric ID') which add value beyond the schema's bare titles. However, it lacks details on format, constraints, or defaults.
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 'Get' and resource 'single rubric with full criteria', clearly distinguishing from the sibling 'get_rubrics' which likely lists all rubrics. The purpose is immediately clear.
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_rubrics'. The description does not state prerequisites, exclusions, or preferred contexts. The agent must infer usage from naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all rubrics for a course.
Args: course_id: Canvas course ID
Returns: {"rubrics": [{id, title, points_possible, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds return structure details but does not disclose side effects, authorization needs, or error handling, which are important for a mutation-free read tool.
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 with two structured sections (args and returns), no wasted words, and front-loads the core purpose immediately.
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 absence of an output schema, the description includes a clear return format and covers the single parameter, making it largely complete for a straightforward list operation, though pagination or filtering nuances are 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?
With 0% schema description coverage, the description compensates by specifying 'course_id: Canvas course ID', adding meaningful context beyond the raw integer type.
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 'Get all rubrics for a course' is a specific verb-resource combination that clearly distinguishes from the sibling tool 'get_rubric' (singular), making the scope 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 implicitly indicates when to use this tool (to retrieve all rubrics) versus the singular alternative, but lacks explicit when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your submission for an assignment, including feedback and comments.
Args: course_id: Canvas course ID assignment_id: Canvas assignment ID
Returns: {id, score, grade, submitted_at, workflow_state, comments, attachments, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes | ||
| assignment_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully convey behavioral traits. It implies a read operation and lists return fields, but does not disclose edge cases (e.g., no submission, errors) or authentication requirements. Minimal addition beyond basic action.
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?
Description is concise (about 5 lines) with structured Args and Returns sections. No redundant wording; every sentence adds value. Slight overhead from listing return fields, but overall efficient.
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 tool with two parameters and no output schema, the description explains it returns the user's own submission with feedback. It clarifies the scope ('your'). Lacks mention of error states or missing submissions, but overall covers essential 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?
With 0% schema description coverage, the description's Args section adds meaning: 'course_id: Canvas course ID' and 'assignment_id: Canvas assignment ID'. This provides basic context but lacks details on constraints or sources. Adequate but minimal.
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 "Get your submission for an assignment, including feedback and comments." It uses a specific verb and resource, and distinguishes from siblings like get_assignments (list) and get_assignment (details without submission).
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 vs. alternatives, such as when to use get_submission versus get_assignment or other sibling tools. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Canvas-computed todo items (assignments needing action).
Returns: {"items": [{type, assignment_name, course_id, due_at, ...}, ...], "count": N}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the return format. It does not mention that the operation is read-only, requires no side effects, or any other behavioral details like authentication needs or rate limits.
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, consisting of one sentence and a return example. It is front-loaded with the purpose and wastes no words. Every part is relevant.
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 tool with no parameters and simple output, the description adequately explains what it returns. It could mention that the data is computed by Canvas, but the context signals suggest it is sufficient for the simple nature of the 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?
The input schema has zero parameters, earning a baseline score of 4. The description adds no parameter information, which is acceptable since none are needed.
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 it returns 'Canvas-computed todo items (assignments needing action)'. The verb 'Get' and resource 'todo items' are specific. However, it does not explicitly differentiate from sibling tools like get_assignments or get_all_upcoming, leaving the agent to infer the distinction.
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 the tool is for retrieving assignments that require action, but it provides no explicit guidance on when to use this tool versus siblings (e.g., get_assignments for all assignments, get_calendar_events for events). No 'when not to use' or alternatives are mentioned.
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.
v1.0.0get_all_gradesget_all_upcomingget_announcementget_announcementsget_assignmentget_assignmentsget_calendar_eventsget_courseget_discussionget_discussionsget_fileget_filesget_full_course_contextget_module_itemsget_modulesget_my_coursesget_pageget_quizget_quizzesget_rubricget_rubricsget_submissionget_todoMost tools target distinct Canvas entities, but there is slight overlap between get_all_upcoming, get_todo, and get_calendar_events, which all deal with upcoming items. However, descriptions help clarify their differences.
All tools follow a consistent 'get_<entity>' pattern with singular/plural differentiation for single vs. list retrieval. The naming is predictable and uniform.
With 23 tools, the count is slightly above the typical range but each tool addresses a specific Canvas feature. The inclusion of get_full_course_context may be redundant, but overall the scope is reasonable.
The tool set is entirely read-only, lacking any create, update, or delete operations. For a Canvas server, this is a major gap that prevents agents from performing essential actions like submitting assignments or posting announcements.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Read-only IELTS and CELPIP question banks, learner practice, progress, scores, and feedback.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
A read-only verified record of agent-operable GTM tools: search, fetch, compare, track changes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cabrt/canvas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server