canvas-scholar-mcp

by Ait0u5hi

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action (courses, assignments, grades, feedback, calendar events, conferences, discussions, etc.). Even overlapping tools like todo, planner, and activity stream have explicit differentiators in their descriptions (e.g., 'prefer this for action needs'), leaving no ambiguity about which to call.
Naming Consistency4/5
The vast majority of tools follow the canvas_<verb>_<resource> pattern (get, list), with snake_case throughout. A few exceptions like canvas_smart_search and canvas_api_usage deviate from the verb_noun structure, but they remain clear and do not disrupt the overall predictable pattern.
Tool Count2/5
43 tools is significantly above the typical well-scoped range. While each tool maps to a specific Canvas API endpoint, the set feels heavy and could potentially be consolidated (e.g., merging multiple list/get pairs). The breadth suggests a comprehensive integration, but it exceeds the threshold where each tool clearly earns its place in a manageable set.
Completeness5/5
The tool set covers the full student-facing Canvas surface: grades, assignments, submissions, feedback, syllabus, calendar, files, modules, pages, quizzes (both classic and new), discussions, announcements, conversations, groups, conferences, peer reviews, search, profile, and API usage. There are no obvious gaps for a read-only student tool, and the exclusion of write operations is appropriate for the stated purpose.
Average 3.9/5 across 43 of 43 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveness. The description adds no behavioral details beyond restating the action—no pagination, sorting, scope behavior, or return format is mentioned. Since annotations cover safety, the low burden is met, but no extra context is provided to qualify for a higher score.
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 concise sentence, front-loaded with the purpose. It is efficient with no fluff, but it duplicates the title without adding new information. Still, for a simple listing tool, this level of brevity is appropriate.
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 tool is simple with only one optional parameter and no output schema. The description states the resource (inbox conversation threads) but does not clarify what the response contains or how scope affects results (e.g., archived or sent are only included if scope is set). Given the sibling tools, a bit more context would help, such as noting that the default scope excludes archived/sent, but the schema partially addresses this.
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 fully documents the single optional 'scope' parameter with an enum and description. The description does not add additional meaning beyond the schema, which aligns with the baseline for high schema coverage (100%). The parameter's purpose is clear from the schema itself.
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 action (list) and the resource (inbox conversation threads). It is specific enough to differentiate from tools like get_conversation or get_unread_count, though it doesn't explicitly name alternatives. The title and description are nearly identical, but the verb and noun make 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?
The description provides no guidance on when to use this tool versus alternatives such as canvas_get_conversation for a specific thread or canvas_get_unread_message_count for counts. No exclusions, scenarios, or hints about when this tool is preferred are given. The single sentence is purely declarative.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context—no mention of pagination, return format, or any side effects. It does not contradict annotations, but it also does not enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single noun phrase. While concise, it is under-specified rather than efficiently informative. It does not follow a structure that front-loads key facts; it simply states a definition. The brevity is not a virtue here because it omits essential usage and behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description minimally covers the resource and scope, but it omits any indication of what the returned data looks like (no output schema), potential error conditions (e.g., group not found), or authorization nuances beyond 'you belong to'. The agent may need to infer expectations from the tool name and sibling context, which is insufficient for confident invocation.
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 single parameter groupId is fully documented in the schema with description 'Canvas numeric id' (coverage 100%). The description adds no further meaning about the parameter's format, constraints, or relationship to the operation. Baseline 3 is appropriate since the schema carries the full burden.
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 the resource ('members') and includes a scope constraint ('of a group you belong to'), which distinguishes it from related tools like canvas_get_group. The verb 'list' is only in the title and not restated, but the noun phrase effectively communicates the operation. It is clear but does not explicitly differentiate from sibling tools such as canvas_get_my_groups.
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 on when to use this tool versus alternatives like canvas_get_group or canvas_list_my_groups. There is no mention of prerequisites, context, or exclusions. The agent is left to infer the purpose from the title and sibling names.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a minimal behavioral detail (due/overdue) but doesn't disclose how results are ordered, whether they include only published assignments, or any other execution behavior. It neither contradicts annotations nor adds substantial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function. It is efficiently front-loaded and contains no filler. However, it is so brief that it leaves out potentially valuable context, though it is not overlong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the core concept but lacks details about return format, pagination, or how results are scoped by default (e.g., all courses or only favorite ones). Given the simplicity, it is minimally viable but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter (courseIds) has a description in the schema ('Optionally limit to these course ids'). The tool description adds nothing about this parameter, so it doesn't exceed the baseline value provided by the schema.
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 (get) and resource (missing submissions, defined as assignments not submitted and due/overdue). It is clear and distinguishes from siblings like canvas_get_todo, though it doesn't explicitly name alternatives. The title and description are similar but not tautological since the description adds the due/overdue 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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention any exclusions, prerequisites, or comparisons to sibling tools such as canvas_get_todo or canvas_get_planner_items. An agent would have to infer the usage context from the tool name alone.
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?
The description adds value beyond the annotations by stating that the output is HTML-stripped and truncated, which is important behavioral information for an agent to set expectations. The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, it does not mention potential truncation length or whether the text includes all sections of a syllabus, leaving some ambiguity, but the description carries modest extra 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 a single, compact sentence that packs essential information: what is returned (syllabus text) and two key transformations (HTML stripped, truncated). There is zero fluff, and every word contributes to agent understanding. It is front-loaded with the core purpose and the transformations are clearly parenthesized.
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 simplicity of the tool (one parameter, no output schema), the description is minimally adequate. It tells the agent what the output looks like but omits any mention of error conditions, authentication requirements, or whether the truncated text is still useful for specific use cases (e.g., extracting course policies). While not critical for a basic getter, the description could provide slightly more context about the expected content of a syllabus to help the agent decide if this tool is appropriate.
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 provides 100% description coverage for the single parameter courseId, so the description does not need to add parameter meaning. The description does not elaborate on the parameter, but the schema already defines it as 'Canvas course id' with a flexible type. This meets the baseline for adequate parameter semantics when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a course's syllabus text, with the specific detail that it is HTML-stripped and truncated. This distinguishes it from sibling tools like canvas_get_assignment or canvas_get_course_page, though it doesn't explicitly name an alternative. The verb 'get' plus the resource 'syllabus' makes 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?
The description provides no guidance on when to use this tool versus the many siblings, nor does it mention any prerequisites or exclusions. There is no hint about alternative tools, such as canvas_smart_search for broader text retrieval, or canvas_get_course_page if heading markup is needed. The agent must infer usage from the name alone.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context, such as response format, latency, or any special conditions. It essentially restates the tool's purpose without enhancing what annotations already convey.
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, focused sentence that is appropriately sized for a tool with no parameters. It is front-loaded with the core information and contains no unnecessary words or filler.
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?
For a simple, parameterless read operation, the description is largely complete. It explains the result (a count) and the scope (unread inbox messages). While it does not specify the exact return type (e.g., integer), the absence of an output schema and the trivial nature of the tool make this a minor omission. An agent can invoke this tool without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is 100% covered (vacuously) and the baseline is 4 per the rubric. The description adds clarifying context by specifying that the count concerns 'unread inbox messages,' which is slightly more specific than the tool name alone. No parameter details are needed.
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 exactly what the tool returns: a count of unread inbox messages. It uses a specific resource (unread messages) and a clear action (get count). It is not a tautology and is distinct from sibling tools like canvas_get_conversation, which fetches a single message, or canvas_list_conversations, which retrieves multiple messages.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that this is the quick way to get an unread count, nor does it contrast with other message-related tools. The agent is left to infer usage from the name, which is straightforward but lacks explicit routing.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the parenthetical 'grading criteria' as domain context, but says nothing about return format, pagination, or any additional behavior. Since annotations carry the safety burden and the description adds minimal extra context, a score of 3 is appropriate.
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, tightly written sentence that front-loads the action and resource. It contains zero filler and is appropriately minimal for a simple list tool. Every word earns its place, meeting the highest standard of conciseness.
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?
For a simple list operation with one parameter and strong annotations covering safety, the description is largely sufficient. It clearly communicates the purpose and implied result (listing rubrics). However, it could explicitly mention that it returns multiple rubrics for the course, and given the sibling canvas_get_rubric, a brief note on when to use this versus that would improve completeness. Still, it is nearly complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with courseId fully described as 'Canvas course id'. The description adds no additional meaning about the parameter beyond the schema. As the baseline for high schema coverage is 3, and no extra parameter context is provided, this score is justified.
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 a specific verb ('List'), a resource ('a course's rubrics'), and adds the clarifier 'grading criteria'. It distinguishes from the sibling canvas_get_rubric by the plural 'rubrics', though it does not explicitly contrast the two. The purpose is unambiguous for a listing tool.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that it lists all rubrics for a course, nor when to prefer it over canvas_get_rubric (which fetches a specific rubric). There is no exclusions or alternative routing, leaving the agent to infer usage from the tool name alone.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context beyond saying 'current grade' and 'every active course', which clarifies scope but does not describe return format, pagination, or other operational details. Since annotations cover the safety profile, a 3 is appropriate.
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 that immediately states the purpose without any fluff or redundant phrasing. It is front-loaded and every word adds value, making it highly efficient.
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?
For a zero-parameter read-only tool with clear annotations, the description is sufficient to understand what the tool returns (current grades for all active courses). It does not elaborate on edge cases like what counts as 'active' or the format of the grade, but given the tool's simplicity and the annotations, this is acceptable. The description could potentially mention that it aggregates across courses, but it already implies that.
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 tool has zero parameters and the schema is empty, so there is nothing for the description to clarify. With no parameters to document, the description is not required to add parameter-level semantics, and the baseline score for such cases is 4.
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 'Your current grade in every active course' uses a clear verb and resource, and explicitly states the scope (all active courses), which helps distinguish it from the more specific canvas_get_course_grade tool. It is not a tautology and conveys a specific action and result, though it does not name sibling tools directly.
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 provides no guidance on when to use this tool versus the many sibling tools, such as canvas_get_course_grade for a single course or canvas_get_missing_submissions for outstanding work. It simply states what it does, leaving the agent to infer usage context from the tool name and title.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the behavioral qualifier 'recent', implying the tool returns only recent announcements, not all. This goes slightly beyond annotations but does not specify what 'recent' means or the exact return structure, so the incremental value is moderate.
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 short sentence, 'Recent announcements for a course.' It is front-loaded with the core purpose and contains no redundant words or filler. It is appropriately sized for a tool with only one parameter and a clear action.
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's simplicity (one parameter, no output schema), the description is mostly adequate but leaves ambiguity around the term 'recent'—there is no explanation of the time window or any limits. Since there is no output schema, a bit more detail about what announcements are returned (e.g., title, date) would improve completeness, but the name and description cover the basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter, courseId, has a description ('Canvas course id') in the schema. The tool description itself does not mention parameters or add any extra meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent announcements for a course, identifying both the resource (course announcements) and the action (list/recent). The title 'List course announcements' reinforces this, and no sibling tool targets announcements, so it is distinct.
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 provides no explicit guidance on when to use this tool versus alternatives, nor any context or exclusions. While it is the only announcement tool among siblings, the description itself does not say 'use this when you need course announcements' or mention any prerequisites, leaving usage entirely to inference.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety expectations. The description adds a minor clarification that the tool can retrieve assignment-dates in addition to calendar events, which is useful but not deeply behavioral. It does not mention potential error responses or authentication requirements, but given the annotation coverage, a moderate score is appropriate.
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 superfluous words. The core action and object are front-loaded, making it immediately scannable for an agent. It effectively conveys the purpose without redundancy.
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?
For a simple get-by-id operation with one parameter, the description, combined with schema and annotations, covers the essentials. There is no output schema to explain return values, so the description could hint at the response structure, but the tool's intent is clear. Minor gaps like error handling are acceptable for such a straightforward retrieval tool.
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 single parameter 'eventId' is fully described in the schema as 'Canvas numeric id', giving 100% schema description coverage. The description merely repeats 'by id' without adding semantic nuance, so the schema carries the burden. Baseline 3 is fitting as no additional meaning is provided beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the specific resource 'one calendar event or assignment-date', and the method 'by id'. It is distinct from the sibling tool 'canvas_list_calendar_events' which lists multiple events, and the agent can easily differentiate them without viewing schemas.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that this is for a single event while listing is for multiple, nor does it reference any contrasting sibling tools. Without such context, an agent may struggle to choose the correct tool in a broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a valuable behavioral detail beyond annotations: 'If the course hides the roster, returns a note instead of an error.' This informs the agent that a non-error response may still indicate unavailability, which is useful for interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no superfluous information. The core purpose is stated first, followed by a key behavioral exception. Every word earns its place.
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?
For a simple one-parameter tool with no output schema and safety annotations covering read-only behavior, the description provides the essential purpose and a notable edge case. It does not describe the return format or fields, but given the tool's simplicity, that is not a critical gap. It is complete enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, courseId, described as 'Canvas course id.' The tool description adds no additional parameter meaning beyond this. Since the schema already documents the parameter adequately, the baseline of 3 applies.
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 'The student roster for a course,' which clearly identifies the resource and scope. It does not explicitly include a verb like 'list,' but the title provides that, and the meaning is unambiguous. It distinguishes from siblings like canvas_list_group_members by focusing on the course roster, though it doesn't name alternatives.
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 no guidance on when to use this tool versus alternatives such as canvas_list_group_members or canvas_list_courses. It only implies use for retrieving the roster, but there is no explicit context, prerequisites, or exclusion criteria. The added behavior about hidden rosters is behavioral, not usage 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety. It adds the scope constraint (only own enrollment) which is useful behavioral context beyond annotations, but it does not disclose return format or potential error conditions.
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 one short sentence with all essential info, no fluff. It is appropriately concise and 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?
For a simple read-only tool with one parameter, the description is adequate but lacks details about the return value structure (e.g., percentage, letter grade) and does not specify when to use this vs alternatives. Given no output schema, a bit more detail would improve completeness.
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 fully describes the single parameter courseId as 'Canvas course id'. The tool description adds no additional meaning beyond that, so baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the caller's grade in a single course, and explicitly notes it only pertains to the caller's own enrollment, which differentiates it from canvas_get_grades (all grades) and canvas_list_courses. The verb is implied by title and context.
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 gives context (single course, own enrollment) but does not explicitly mention when to use this over canvas_get_grades or other tools. The distinction is implied by the name and wording, but no explicit alternative or exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the returned 'url' is a ready-to-use download link, which is useful behavioral context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The key benefit (download link) is front-loaded, and the description is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only get with annotations covering safety and no output schema, the description provides everything needed: what it returns (metadata) and the key detail about the URL. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the single parameter ('Canvas numeric id') at 100% coverage, so the description adds no additional parameter meaning but is not required to. Baseline 3 applies.
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?
States a specific verb ('get') and resource ('file') with metadata by id. Distinct from siblings like canvas_list_course_files which lists files, so the purpose is clear, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The name implies retrieval by id, but there is no mention of exclusions or when to prefer other tools like canvas_list_course_files.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that the result includes 'criteria and assessments,' which gives some insight into the return content. However, it does not disclose error handling, permission requirements, or response structure beyond that.
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 is concise and front-loaded with the core action ('Get one rubric') and immediately specifies the key content. No wasted words, and the most important information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET tool with two well-documented parameters, the description gives a basic sense of the return payload ('criteria and assessments') but omits details like response format, potential errors, or prerequisite permissions. Given the absence of an output schema, it does not fully compensate, but it is adequate for a straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both courseId and rubricId having meaningful descriptions. The tool description does not add any additional parameter nuance, so a baseline score of 3 is appropriate given the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves one specific rubric by ID, and it specifies the resource ('rubric') and its contents ('criteria and assessments'). This distinguishes it from listing tools like canvas_list_course_rubrics and other get tools, which are about different entity types.
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 a single-rubric fetch ('one rubric'), but it does not explicitly contrast with canvas_list_course_rubrics or state when to prefer one over the other. An agent would infer that a specific rubric ID is needed, but there is no explicit guidance on alternatives or conditions.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the qualifier 'wiki/content' but nothing else about response structure, pagination, or auth. It is consistent with annotations but adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It gets to the point immediately. While brief, it is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately states the action but omits details like pagination or that it returns an array of page metadata. Given the annotations cover safety, this is adequate but not complete. It could mention what the list contains or hint at the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both courseId and searchTerm. The description does not add any additional meaning beyond the schema's 'Filter by title' for searchTerm. Baseline 3 applies because the schema does the heavy lifting.
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') with a clear resource ('a course's wiki/content pages'). It clearly distinguishes from the sibling tool canvas_get_course_page, which would fetch a single page. The purpose is unambiguous.
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 states the action but provides no guidance on when to use this tool versus alternatives, particularly canvas_get_course_page for a single page. It does not mention searchTerm filtering or any exclusions. The usage context is implied but not explicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the behavioral safety profile is covered. The description adds content details (threaded view, reply bodies) but no further behavioral traits such as pagination, rate limits, or return format specifics. This is consistent and adds modest value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's output and scope without any redundant phrasing. It is appropriately concise for a simple read operation, with no filler or unnecessary detail.
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?
For a two-parameter read-only tool with no output schema, the description provides adequate context about the return content (full thread with reply bodies). It could be more explicit about other response elements (e.g., author info, attachments), but for a straightforward retrieval tool this is sufficient. The annotations cover safety and open-world behavior, so the description is reasonably complete.
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?
Both parameters (courseId and topicId) have full schema descriptions, giving 100% coverage. The tool description adds no additional parameter details, so it does not exceed the schema baseline. Since the schema already documents parameter meaning, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it provides a 'full threaded view of a discussion topic, including reply bodies.' This distinguishes it from sibling tools like canvas_list_discussions, which list topics rather than return thread content. The meaning is unambiguous and ties directly to the tool name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing a specific discussion's full thread, but it does not explicitly state when to use this tool versus alternatives like canvas_list_discussions. No exclusions or alternative conditions are mentioned, leaving the agent to infer from the sibling list. This is adequate but lacks explicit routing.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond the annotations, such as return format or error handling. It does not contradict the annotations, so a score of 3 is appropriate since it adds minimal value beyond what annotations provide.
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, front-loaded sentence with no unnecessary words. It communicates exactly what the tool does in the most efficient way, making it perfectly concise.
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?
For a simple get-by-id tool with two required parameters, no output schema, and annotations covering safety, this description is largely sufficient. It lacks explicit mention of the return object or typical error scenarios, but given the tool's simplicity, these gaps are minor. It is complete enough for an agent to correctly call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both courseId and quizId having descriptions ('Canvas course id' and 'Canvas numeric id'). The description does not add any parameter-specific meaning beyond these schema descriptions, so it leverages the schema rather than enhancing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'one classic quiz by id', which precisely identifies the tool's function. The qualifier 'classic' differentiates it from sibling tools like canvas_list_new_quizzes and canvas_list_quizzes, making it unambiguous.
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 conveys that this is a retrieval tool for a specific quiz by ID, which is clear from 'by id'. However, it provides no explicit guidance on when to use this instead of list-based tools or any alternative selection criteria. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the 'metadata only' qualifier, which clarifies that the tool does not return full discussion content — useful context beyond the annotations. No contradiction.
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 one short sentence that front-loads the core purpose and includes the qualifier 'metadata only'. There is zero filler; every word contributes.
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?
For a simple list tool with one parameter and no output schema, the description fully covers what the agent needs to know to invoke it correctly. It could mention that no pagination is needed or that the result is an array, but this is not essential given the lack of output schema. Slightly incomplete because it doesn't hint at what the response looks like (e.g., array of topic objects), but overall sufficient.
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 single parameter courseId is fully described in the schema (coverage 100%), so the description doesn't need to add parameter semantics. The description adds no extra meaning about the parameter beyond what the schema provides, giving the baseline 3.
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+resource ('List discussion topics') and adds a scope qualifier ('in a course') plus a useful behavioral qualifier ('metadata only'). This clearly distinguishes it from content-fetching tools like canvas_get_discussion_view, even without naming them.
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 the primary use (listing topics) but provides no guidance on when to choose this over alternatives, when it's not appropriate, or any exclusions. While the 'metadata only' qualifier hints at a difference, it doesn't explicitly state 'use this when you need only the index, not the full discussion content'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds useful behavioral context: the default date range (yesterday..+14 days) and that this is the unified 'what's due/new' feed. This goes beyond the structured metadata, though it doesn't cover pagination or return format, which are not critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each contributing distinct information: what it returns, the default date window, and its unified nature. There is no fluff, and the most important info (resource type) is front-loaded. Efficient and well-structured.
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?
For a read-only planner feed with two optional date parameters and no output schema, the description is reasonably complete. It specifies the item types and the default window. It doesn't detail the output structure, but since there is no output schema and the tool is straightforward, this is acceptable. The title clarifies it's 'my' planner. Minor gap: it could mention that only the current user's items are returned, but the title implies that.
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 100%, so the baseline is 3. The description adds value by explaining the default behavior when startDate/endDate are omitted, which is not present in the schema. This helps the agent understand that the parameters are optional and that a default window applies, enhancing the parameter semantics beyond the schema.
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 returns 'Planner items (assignments, quizzes, events) in a date window' and positions it as Canvas's unified feed. This is a specific verb-resource pairing with a defined scope. It doesn't explicitly name sibling tools for differentiation, but the 'unified' qualifier helps separate it from single-type tools like calendar_events or todo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the default date window and the unified nature, but it does not explicitly say when to prefer this over siblings like canvas_get_todo or canvas_get_activity_stream. No exclusions or alternatives are mentioned, leaving the agent to infer when this is the right choice. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by specifying that the response includes the user's submission, a behavior not noted in annotations or schema. This contextual detail helps the agent set expectations about the returned data without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, object, and distinguishing detail (submission inclusion and id-based retrieval) efficiently. Every word earns its place, making it easily scannable for an agent.
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?
For a simple read-by-id tool with full schema coverage and safe annotations, the description is largely sufficient. It covers the key behavioral detail (inclusion of submission). Minor gaps like error cases or response format are mitigated by the tool's simplicity and the presence of annotations. An output schema is absent, but the description adequately conveys what is returned for intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both required parameters (courseId and assignmentId). The description adds no additional meaning beyond the 'by id' phrasing, which is redundant with the schema. Since the schema fully documents parameters, the description provides minimal extra value, matching the baseline of 3.
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 'Get' with a specific resource 'one assignment' and adds the contextual detail '(with your submission)' and 'by id'. This clearly distinguishes it from listing tools like canvas_list_assignments and other assignment-related tools. The agent can immediately understand the exact operation and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'by id', suggesting it is for retrieving a specific known assignment rather than listing all assignments. However, it does not explicitly state when to prefer this over alternatives like canvas_list_assignments or canvas_get_submission_feedback. The guidance is implicit through the id requirement but lacks explicit exclusions or naming of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explains that the tool may return a note if instructor-restricted, and describes the content structure (deduction % per interval). This enriches the agent's understanding of potential outcomes without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary purpose, and includes only relevant details. There is no filler or redundant phrasing, and the fallback note is placed after the core functionality, maintaining a logical structure.
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 the tool's simplicity (one parameter, no output schema), the description provides a good overview of what is returned (penalty tiers with deduction percentages) and a key edge case (instructor restriction). It does not detail the exact JSON structure, but for a read-only retrieval tool, the information is sufficient for an agent to know what to expect and how to handle a restricted scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, as the courseId is described with type and pattern. The description does not add any additional meaning about the parameter (e.g., format, source, or constraints) beyond what the schema already provides. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a course's late-submission penalty tiers with specific detail ('deduction % per interval'). This is a specific verb+resource combination that distinguishes it from sibling tools like canvas_get_grading_standards or canvas_get_syllabus, which serve different purposes.
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 does not explicitly compare against sibling tools or state when to prefer this over alternatives. It does mention a conditional fallback ('if the course restricts this to instructors, returns a note so you can fall back to the syllabus'), which offers some guidance on handling restricted access, but it lacks explicit exclusions or selection criteria.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds no new behavioral context (e.g., what happens if no submission exists), but the annotation coverage lowers the bar. It neither contradicts nor enriches beyond the structured data.
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 7-word sentence that encapsulates the entire purpose with zero fluff. It is front-loaded and every word earns its place.
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?
For a simple two-parameter, read-only tool with no output schema, the description is nearly complete. It doesn't describe return values, but there is no output schema to set expectations, and the purpose is unambiguous. Minor omission: no explicit mention of handling missing submissions, but that's not strictly necessary given the read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described ('Canvas numeric id' and 'Canvas course id'). The tool description does not add additional semantics beyond the 'classic quiz' qualifier, which is implicit in the purpose. Baseline 3 is appropriate when the schema carries the load.
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 it gets the user's own attempt/submission for a classic quiz. It distinguishes from sibling tools like canvas_get_quiz (quiz details) and canvas_get_submission_feedback (feedback) by specifying 'own' and 'classic', making the resource and scope precise.
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 implies usage (retrieve your own submission for a classic quiz) but does not explicitly list alternatives or when not to use. However, the sibling names make the distinction obvious, so the usage context is clear without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds that locked/hidden folders are excluded automatically, which is a valuable behavioral detail beyond the safety profile. This informs the agent that results may be incomplete for inaccessible files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The purpose is front-loaded, and the behavioral note is concise. Ideal length for a simple list operation.
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?
For a low-complexity list tool with full annotation coverage and no output schema, the description conveys purpose and a key behavioral caveat. It could optionally mention recursion or pagination, but those are not critical for basic usage. Essentially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (courseId and searchTerm) having clear descriptions. The description adds no parameter-specific meaning beyond the schema, so it does not compensate for or expand on the existing parameter documentation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'list' and resource 'files in a course' precisely. It clearly distinguishes from sibling canvas_list_course_folders (folders) and canvas_get_file (single file) by naming the specific resource. The additional note about locked/hidden folders adds useful specificity.
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 purpose implies when to use (when course files are needed), but there is no explicit differentiation from similar tools like canvas_list_course_folders. The note about exclusion hints at a limitation but does not guide the agent to alternatives or when not to use this tool.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, covering safety. The description adds the navigational purpose but does not disclose details like pagination, ordering, or whether nested folders are returned. With annotations carrying the safety profile, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the primary action and purpose. No wasted words; every element earns its place.
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?
For a simple read-only tool with one parameter and no output schema, the description is sufficient. It gives the purpose and the only parameter is already documented. A minor gap is that it doesn't specify whether the result includes only top-level folders or all nested folders, but this is not critical for a listing operation.
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 describes courseId as 'Canvas course id' with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. The tool has only one parameter, so there is little to compensate for.
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+resource: 'List a course's folders'. It is distinct from siblings like canvas_list_course_files (files vs folders) and canvas_get_file. The parenthetical 'for navigating the file tree' further clarifies its role, making it easy to differentiate.
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 gives clear context: 'for navigating the file tree' implies when to use it. It does not explicitly name alternatives or exclusions, but the sibling landscape makes it obvious that this is for folders, not files or other resources. It lacks an explicit 'use X instead when...' but the intent is clear.
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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds the output content (grade, progress, staff) but does not disclose any operational behaviors beyond that, such as pagination, ordering, or timeouts. With annotations present, 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 a single, well-structured sentence that leads with the core purpose and then lists the key data points. Every word earns its place; no filler or redundancy. It is front-loaded and easy to scan.
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?
For a simple list tool with one optional parameter, the description provides a clear idea of what will be returned (courses with grade, progress, staff). There is no output schema, so the description partially compensates by naming the fields. It does not mention pagination or ordering, but these are likely negligible for a personal course list. It is sufficiently complete for an agent to call correctly.
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 sole parameter includeConcluded is fully described in the schema (coverage 100%), so the schema carries the explanation. The description does not mention parameters or add any additional semantic context. Baseline 3 is appropriate because the description adds no value beyond the schema.
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 clear verb ('List') and resource ('courses you are enrolled in'), and specifies exactly what data is included: grade, module progress, and teaching staff. This distinguishes it from siblings like canvas_get_grades or canvas_list_modules, which focus on narrower aspects. No ambiguity about what this 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is the one-stop tool to see a comprehensive overview of one's courses, including grades and progress, rather than calling multiple other tools. It does not explicitly name alternatives or state when not to use it, but the context is clear that it aggregates data for a single course list. Since no exclusions are provided, it slightly misses the top bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar for behavioral disclosure is lower. The description adds value by specifying that the result includes the modules' items, which informs the agent of the return content. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the action ('List modules in a course') and then adds the important qualifier ('with their items'), making every word earn its place.
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?
For a simple tool with one parameter and annotations covering safety, the description is largely complete. It states the core action and the inclusion of items, which hints at the return structure. However, with no output schema, it could be more explicit about the response format, though this is a minor gap given the simplicity.
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 input schema already provides a full description for courseId ('Canvas course id'), and schema description coverage is 100%. The tool description adds no additional parameter semantics, so per the rubric, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('modules') with a clear scope ('in a course') and elaborates that it includes items. This is unambiguous and distinguishes it well from the many sibling tools that list other course resources like files, pages, or assignments.
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 its usage by stating exactly what it does, but it does not provide explicit guidance on when to choose this tool over alternatives or any exclusions. Since there are no sibling tools for modules, this absence is acceptable, but the description still lacks any contextual when-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a specific behavioral detail: 'Does not mark it as read (stays read-only)', which explicitly guarantees that the tool does not alter conversation read state. This goes beyond the generic annotation and provides useful context for an agent.
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 two concise sentences that front-load the primary action ('Read one inbox conversation thread') and then add a clarifying behavior. There is no filler or redundant content, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, no output schema, and annotations covering safety and idempotency, the description is complete. It conveys the core action, the read-only guarantee, and implicitly differentiates from list operations. No additional information is needed for correct invocation.
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 input schema already provides 100% coverage with a description for conversationId ('Canvas numeric id'), which is sufficient baseline. The tool description does not add additional meaning about the parameter's format, constraints, or usage beyond what the schema states. No extra context is needed for this single-parameter tool.
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 ('Read') and a specific resource ('one inbox conversation thread'), which clearly distinguishes it from sibling tools like canvas_list_conversations (which lists threads) and canvas_get_unread_message_count. It also adds precision by clarifying the scope ('one') and the read-only nature.
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 usage context is implied through the name and description: to read a specific thread, as opposed to listing all threads. However, there is no explicit mention of when to use this tool versus alternatives like canvas_list_conversations, nor any stated exclusions. The description implies usage but does not provide clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent, so the safety profile is covered. The description adds valuable behavioral detail by specifying that the output is 'HTML stripped to text', which informs the agent about the response format. This goes beyond the annotations and aids in setting expectations for the returned data.
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 sentence with no filler words. It front-loads the action and resource, then appends a crucial qualifier about HTML stripping. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with only two required parameters, both well-documented in the schema, and annotations covering safety, the description is sufficient. It explains the output format (stripped text) and the tool's purpose. No additional information is necessary for an agent to invoke it correctly; an output schema is not present, but the return content is described sufficiently.
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 input schema provides descriptions for both parameters: 'Canvas course id' and 'Page url slug or id'. With 100% schema description coverage, the schema already carries the semantic weight. The description adds no additional parameter context, which is acceptable given the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'one wiki page', and adds the specific detail 'content (HTML stripped to text)'. This precisely distinguishes it from sibling tools like canvas_list_course_pages, which lists pages, and other getters. The purpose is unambiguous and directly maps to the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single page's content, but it does not explicitly mention when to prefer this over alternatives like canvas_list_course_pages or when not to use it. There is no exclusionary guidance or mention of alternatives, leaving the agent to infer context from the sibling tool names. Clear context exists but no explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a valuable behavioral detail: 'Drop rules are reported but not pre-applied.' This goes beyond annotations and helps the agent understand a subtle aspect of the returned data. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The main purpose is front-loaded, and the important caveat about drop rules is concisely stated. Every word earns its place.
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?
For a read-only tool with one parameter and no output schema, the description explains what is contained in the response (weights, submissions, weighted breakdown) and the key exception (drop rules not pre-applied). This is sufficient for an agent to understand the tool's behavior and integrate it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (courseId), which is described as 'Canvas course id.' The description does not add parameter-specific context, but since the schema is complete, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (get), the resource (assignment groups), and the specific purpose (weighted breakdown behind a course grade). It distinguishes itself from siblings like canvas_get_course_grade (which likely returns a single grade) and canvas_get_grades (which might return actual grades). The phrase 'with their weights and your submissions' precisely defines the return contents.
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 context: it shows the weighted breakdown behind a course grade, implying this tool is used when understanding grade composition is needed. It does not explicitly mention alternatives or when not to use it, but the purpose is evident enough that an agent can infer appropriate usage from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context by enumerating the return contents (comments, rubric, attempt history) and the 'your submission' scope. It does not repeat annotation flags, and it explains what data is returned beyond the tool name. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core functionality and the expected content, followed by a concrete usage example. There is zero fluff, and every sentence earns its place. Perfectly concise for an agent to parse.
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?
For a read-only tool with only two parameters and no output schema, the description adequately conveys what the tool returns (comments, rubric, attempt history) and its scope ('your submission'). It lacks explicit mention of error cases or pagination, but these are minor for such a simple tool. The example query further anchors its use. Overall, sufficient context for correct invocation.
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 provides 100% coverage for courseId and assignmentId with descriptions, so the baseline is 3. The description does not add parameter-specific guidance (e.g., format or validation), but it implicitly clarifies that both are required and used to identify the assignment. No additional semantics beyond schema are provided, which is acceptable given full schema coverage.
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 ('get'), resource ('submission feedback'), and scope ('for one assignment'), and clarifies the content (professor's comments, rubric assessment, attempt history). It is clearly distinct from sibling tools like canvas_get_grades or canvas_get_assignment, which serve different purposes.
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 explicitly ties usage to a natural-language query ('what did my professor say / how was I graded?'), giving a clear trigger. It does not name alternative tools or state when not to use it, but the sibling list and the focused example guide the agent well. Slight gap in explicitly excluding other grade-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description is consistent with them (no contradiction). On top of that, the description adds genuine behavioral context: the conditional nature of class statistics ('when Canvas allows it') and the disclosure that New Quizzes surface here. This meaningfully exceeds what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero filler. The core action and return contents are front-loaded, followed by the conditional statistics caveat and a practical edge-case note. Every sentence carries information.
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?
For a simple list tool with 2 params (1 required) and no output schema, the description covers the action, what is returned, and an important data-inclusion caveat. Minor gaps exist — no mention of pagination, ordering, or response shape — but nothing an agent critically needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents courseId and bucket (with enum values explained). The description adds no parameter-level detail beyond the schema; the 'New Quizzes' note relates to tool behavior rather than parameter semantics. Baseline of 3 is appropriate given full schema coverage.
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?
States a specific verb (list), resource (assignments in a course), and enriches the purpose by naming what is returned (submission status, conditional class score statistics) and the intended use (comparison). The 'New Quizzes' note further differentiates it from siblings like canvas_list_quizzes and canvas_get_assignment. Purpose is 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?
The trigger condition ('list assignments in a course') is clear, and the New Quizzes note gives practical routing guidance (quiz-related lookups may need this tool). However, it never explicitly names alternatives or states when NOT to use it versus canvas_get_grades, canvas_get_assignment, or canvas_list_quizzes. Context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it returns join links, covers live/scheduled sessions, and clarifies the distinction from calendar events. It does not mention pagination or response format, but the safety profile is well covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core purpose is front-loaded, and the calendar distinction is included in the same breath. Every word earns its place.
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?
For a simple read-only list tool with no output schema, the description is near-complete. It mentions scope (all courses or one), join links, and the calendar distinction. It does not mention pagination or rate limits, but these are not critical for a tool of this simplicity and the annotations already establish safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The description adds marginal value by implying the state filter ('live' only) and the courseId scope, but it does not elaborate on parameter syntax or behavior beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists web conferences (BigBlueButton class sessions) with join links, across all courses or one course. It explicitly differentiates itself from calendar events, making its purpose unambiguous and distinct from sibling tools.
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 guidance on when to use it: 'These are NOT in the calendar, so use this to catch live class sessions.' It implies the alternative (calendar events) and gives a specific use case. However, it does not explicitly name other tools or provide exclusions beyond the calendar distinction.
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?
Annotations already declare readOnlyHint: true, openWorldHint: true, idempotentHint: true, and destructiveHint: false, so the description doesn't need to restate safety. It adds the behavioral detail that the result is a combination of course project groups and community groups, which goes beyond annotations and helps the agent understand the scope of results. However, it doesn't mention potential pagination or ordering, which is a reasonable gap for a simple list tool.
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 is both informative and succinct. It front-loads the core purpose and includes the defining nuance (types of groups) without any filler.
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?
For a tool with no parameters and no output schema, the description is sufficient. It tells the agent exactly what will be returned (a list of groups they belong to) and clarifies the group types. Since it's a simple list endpoint, no additional documentation like pagination details or response format is strictly necessary, though slightly more output detail could be added.
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 tool has zero parameters, so the description doesn't need to explain any. Baseline for 0 params is 4, and the description doesn't lack anything here.
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 the specific verb 'list' and the resource 'groups' with a clear scope 'all groups you belong to'. It further specifies 'course project groups + community', which distinguishes it from other group-related tools like canvas_get_group (retrieves a single group) and canvas_list_group_members (lists members of a group).
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 clearly implies when to use it: when you need all groups the current user belongs to. It doesn't explicitly exclude alternatives, but the sibling tools for fetching a specific group or listing group members are obviously different. It provides useful context by naming the group categories.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by explaining the default filtering to only the user's assigned reviews and how to opt out, though it does not disclose pagination, ordering, or returned review fields.
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, well-structured sentence that leads with the core purpose and immediately follows with the key behavioral nuance. Every word contributes useful information and there is no redundancy with the schema or annotations.
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?
For a simple 3-parameter list tool with read-only and non-destructive annotations, the description covers the essential behavior and parameter override. While no output schema exists and the description does not detail response fields, that is not necessary for selecting and invoking 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 coverage is 100%, so the input schema already documents courseId and assignmentId. The description adds meaning beyond the schema by explaining the mineOnly parameter's default behavior and its effect, which helps the agent decide whether to override it.
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 the specific verb 'returns' and clearly identifies the resource as 'peer reviews for an assignment.' It also clarifies the default scope ('assigned to YOU'), which distinguishes this tool from other Canvas listing tools and makes its purpose immediately understandable.
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 indicates when to use the tool by framing it as listing peer reviews for an assignment, and explicitly explains how to change the default behavior with 'mineOnly=false for all.' It does not name alternative tools outright, but the context is sufficiently clear for selecting this tool over the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, covering the safety profile. The description adds value beyond these by disclosing its beta status and the fact that it returns a note when not enabled for the course. This extra behavioral context is useful and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose and scope, and includes only necessary details (ranking logic, use case, beta note). No filler words or redundant phrasing; every sentence earns its place.
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?
For a search tool with no output schema, the description covers the key aspects: what is searched, how results are ranked, and a special condition (not enabled). It does not describe the return format or result limits, but given the annotations already cover safety and idempotence, this is reasonably complete. More detail on output shape would improve it, but it is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as both parameters have descriptions (query as natural language, courseId as Canvas id). The description adds no significant new semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('search') and a well-defined resource scope ('pages, assignments, announcements and discussions') and explicitly distinguishes itself from keyword search ('ranked by meaning'). It clearly separates from sibling getter tools that target individual resources, making the tool's unique cross-resource semantic search purpose obvious.
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?
It provides a clear when-to-use context with a concrete example ('where did we cover X?'), which implies semantic queries across content. However, it does not explicitly name alternative tools or state when not to use it (e.g., 'for keyword search, use list tools'). The guidance is implicit rather than explicit, so it does not achieve a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering safety and idempotency. The description adds meaningful behavioral context beyond annotations by noting that it 'Returns a note if restricted to instructors' — a permission-related edge case. It also provides a format example (A ≥ 93) that implies the output structure. These additions justify a 4, since the annotations lower the burden and the description enriches it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The primary purpose is front-loaded, the example is illustrative, and the instructor-restriction note is placed at the end without disrupting the core message. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent tool with a single parameter and no output schema, the description fully covers what an agent needs: the resource, its purpose, a typical user question, and an edge case (instructor restriction). Nothing essential is missing for an agent to decide whether to invoke it and to understand the expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the single parameter courseId is described as 'Canvas course id'. The tool description does not add any additional parameter-level detail beyond what the schema already provides, but it also doesn't need to. With full schema coverage, the baseline of 3 is appropriate, and the description does not introduce conflicts or ambiguity.
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 retrieves a course's letter-grade cutoff scheme with a concrete example ('A ≥ 93, etc.') and its intended use case ('what do I need for an A?'). This differentiates it from siblings like canvas_get_course_grade (which returns a student's grade) and canvas_get_grades (which lists grades). The verb 'get' plus resource 'grading standards' is specific and 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?
The description explicitly ties usage to a common question ('for 'what do I need for an A?'') which gives clear contextual guidance. It does not explicitly name alternative tools or state when not to use it, but its purpose is self-evident enough that an agent would know to use it for cutoff thresholds rather than actual grades. This meets the 'clear context, no exclusions' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description need not repeat those. It adds the membership constraint ('you belong to'), which is beyond the annotations and useful for access control expectations. No contradictions with the readOnlyHint.
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 that immediately conveys the core purpose and a key constraint (membership). No unnecessary words or redundancy; it is optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with comprehensive annotations and a single required parameter, the description covers the essential information: what it does and the scope (groups you belong to). With no output schema needed and straightforward behavior, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the groupId parameter described as 'Canvas numeric id.' The description adds no additional parameter detail beyond the schema, which is adequate given the high coverage. A baseline of 3 is appropriate since no extra guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns details for a single group, using the possessive 'you belong to' to imply membership scope. It distinguishes itself from siblings like canvas_list_my_groups (list) and canvas_list_group_members (members) by specifying 'one group' and 'you belong to.' The verb is implicit but reinforced by the title 'Get a group'.
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 phrase 'one group you belong to' gives clear context that this is for retrieving a single group's details, differentiating from list operations. However, it does not explicitly name alternate tools or conditions for when not to use this tool, though the implication is clear.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile well. The description adds the specific distinction between classic and New Quizzes, which is useful context but not additional behavioral disclosure beyond what annotations imply. No contradiction exists, and the added value is modest, so a 3 is appropriate.
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 two sentences with zero wasted words. The core action is front-loaded, and the critical exclusion (New Quizzes) is stated immediately after. It is highly concise and well-structured, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter, no output schema, and annotations that already cover safety and idempotency, the description is complete. It tells the agent exactly what will be returned (classic quizzes) and what will not, and the instruction is self-contained. Nothing essential is missing.
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 provides 100% coverage for the single parameter (courseId) with a description. The description does not add any extra meaning to the parameter beyond what the schema states. Per the rubric, baseline 3 is given when schema covers parameters fully, and there's no additional information provided in the description.
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) and resource (classic quizzes in a course), and explicitly distinguishes from New Quizzes, which is a key differentiator among sibling tools like canvas_list_assignments and canvas_list_new_quizzes. The purpose is unambiguous and immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to list classic quizzes) and when not to (New Quizzes do not appear here), and provides the alternative (canvas_list_assignments). This is direct usage guidance with a named alternative, fulfilling the requirement completely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior. The description adds value by explaining the mechanism (via assignment shells) and the instructor-gated limitation for question reading, giving context beyond the annotation flags without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, then the exclusions and a caveat. Every sentence adds information and there is no padding or repetition.
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?
For a simple list tool with one required parameter, the description conveys what it returns (a list of New Quizzes), how it works (via assignment shells), and what it doesn't cover (due dates/points/status). It's complete enough for an agent to call correctly, though an output schema would further clarify the return shape.
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 fully documents the single parameter courseId with type and pattern, and schema coverage is 100%. The description adds no additional parameter-specific information, so the baseline of 3 is appropriate; the description doesn't enhance parameter understanding beyond the schema.
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?
States clearly what it does: lists a course's New Quizzes (Quizzes.Next engine), and explicitly distinguishes it from the sibling canvas_list_quizzes by noting those quizzes don't appear there. The verb 'List' and resource 'New Quizzes' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance by referencing the alternative (canvas_list_quizzes) and explaining that this tool finds New Quizzes via assignment shells. It also cautions about the instructor-gated API for reading questions, helping agents set expectations about what fields are not available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: it specifies the exact outputs (request count and remaining budget) and explains the throttling rationale. No contradiction exists, and the description enriches the safety profile with session-specific details.
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 two sentences with zero filler. The first sentence states the core purpose and outputs, and the second sentence provides motivation and timing. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, output-schema-less tool, the description is fully complete. It explains what the tool does, what it returns, and when to use it. There is no missing information an agent would need to invoke it 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?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, a baseline of 4 is appropriate since there are no parameters to document. The description doesn't need to add parameter semantics because there are none.
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 and resource: 'check Canvas API budget' and specifies what it returns (request count and remaining rate-limit budget). It clearly distinguishes from all sibling tools, none of which are about API usage. The purpose is unambiguous and actionable.
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 guidance on when to use it: 'this lets you check before running something big' due to Canvas throttling heavy bursts. It doesn't explicitly state when not to use it, but given the tool's simplicity and lack of alternatives, this is sufficient. The context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds value by specifying exactly which profile fields are returned (name, avatar, primary email), which goes beyond the annotations and helps the agent know what to expect.
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 that immediately states the resource and its contents. It is front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and a simple deterministic purpose, the description fully covers what the agent needs to know. It specifies the return content adequately, even without an output schema.
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 tool has zero parameters, so there is nothing to explain. Per the calibration baseline, a score of 4 is appropriate when a tool has no parameters, as there is no ambiguity about arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (your Canvas profile) and the specific data returned (name, avatar, primary email). It is unambiguous and distinguishes this tool from all siblings, none of which mention profile retrieval.
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?
While there is no explicit 'use this when' guidance, the tool's purpose is self-evident and no sibling tool overlaps. The context of the toolset makes it clear this is the only profile-fetching tool, so the usage context is implied without explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety. It adds operational details beyond annotations: the default date window (yesterday..+14 days), automatic derivation of course contexts, and the conference exclusion. This enriches the behavioral profile without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, then alternatives, then a cautionary note. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description covers the essential context: what is returned, the default window, automatic scoping, and exclusions. It also names alternatives for different needs. Nothing critical is missing for an agent to decide on and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (type and courseIds have descriptions; startDate/endDate lack any description). The description adds the default date window but does not specify the expected date format for startDate/endDate, nor does it clarify that they are optional. It partially compensates for the gaps but leaves the syntax ambiguous, so an agent might format dates incorrectly.
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 it lists calendar events and assignment dates across courses, with a specific verb and resource. It differentiates from siblings by mentioning planner for due feed and conferences as separate tools, so an agent can distinguish it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: 'Use planner for the unified due feed; use this for raw calendar events like office hours.' Also notes an exclusion with an alternative: 'live web conferences do NOT appear here — use canvas_list_conferences for those.' This fully covers when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds behavioral context by specifying the feed's nature (social/notification) and the included item types, which helps set agent expectations. It does not mention ordering or pagination, but given the annotations and simplicity of the tool, the added context is sufficient.
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 sentence followed by a short routing hint. It is front-loaded with the content types and the distinguishing pointer to alternatives. There is no redundant wording or unnecessary detail, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with robust annotations and no output schema, the description provides complete context. It states what the tool returns (recent activity) and explicitly routes the agent away for action items. No essential information is missing for correct invocation.
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 tool has zero parameters, and schema description coverage is trivially 100% since there are no properties. According to the baseline rule for 0-param tools, a score of 4 is appropriate. The description does not need to explain any parameters, and none are missing.
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: 'Your recent Canvas activity' and lists concrete content types (announcements, messages, submissions). It clearly positions the tool as the social/notification feed and distinguishes it from action-oriented siblings by naming the alternatives (planner, todo). This is enough for an agent to select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to prefer other tools: 'for action items prefer planner or todo.' This gives clear guidance on usage context and alternatives, going beyond mere purpose to direct the agent toward the correct choice among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by clarifying the semantic scope (action-needed items) and how it relates to overlapping tools, which goes beyond the structured fields. No contradictions.
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?
One concise sentence with no filler. The primary purpose and scope are front-loaded, and the overlap clarification is appended efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with annotations covering safety and no output schema, the description fully covers what an agent needs: what the list represents and when to use it. Nothing essential is missing.
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?
Tool has zero parameters, so the baseline is 4. The description adds no parameter info (none needed), and the schema coverage is 100% (trivially). This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('get') and resource ('to-do list') with a clarifying phrase ('items needing action right now'). Explicitly distinguishes from sibling tools by naming the overlaps with planner and activity stream, so an agent can tell it apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'prefer this for what needs action'. Also names the alternatives (planner with dated window, activity stream as feed) and implies the conditions under which they would be more appropriate, leaving no ambiguity about selection.
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-scholar-mcp MCP server](https://glama.ai/mcp/servers/Ait0u5hi/canvas-scholar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Ait0u5hi/canvas-scholar-mcp)

Score Badge

Copy to your README.md:

[![canvas-scholar-mcp MCP server](https://glama.ai/mcp/servers/Ait0u5hi/canvas-scholar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Ait0u5hi/canvas-scholar-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/Ait0u5hi/canvas-scholar-mcp'

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