Canvas Agent

Server Quality Checklist

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

Latest release: v2.0.2
Disambiguation4/5
Most tools target distinct resources and actions, with clear descriptions separating similar-sounding ones (e.g., list_students vs list_users_in_course vs list_gradeable_students). However, the sheer volume of analytics and listing tools (get_student_activity, get_course_activity, get_student_summaries, get_student_assignment_data) creates some potential for misselection despite distinct descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_calendar_events, create_module, update_assignment, delete_rubric). There are no camelCase or mixed conventions, and multi-word verbs like batch_update are uniform across the set.
Tool Count2/5
With 80 tools, this is far beyond the typical well-scoped range (3-15) and even beyond the 'heavy' threshold of 25+. While the Canvas domain is broad, this many tools creates an overwhelming surface, and many tools could be consolidated (e.g., separate date-update tools, multiple student-listing tools).
Completeness3/5
The set covers core workflows for assignments, quizzes, discussions, modules, rubrics, and submissions, but there are notable gaps: several descriptions reference tools like create_course, list_term_courses, and list_outcomes that are not present. This forces reliance on other MCPs, making the surface feel incomplete on its own.
Average 4.1/5 across 80 of 80 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'List' implies a read-only operation with no side effects, which is adequate for a simple retrieval. However, it does not mention pagination, ordering, or the exact scope of 'all items' beyond what the name suggests.
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 gets straight to the point. It contains no unnecessary filler or repetition, making it highly efficient.
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?
This is a simple tool with two parameters and no output schema. The description is minimally sufficient, but it lacks context about what 'items' includes (e.g., assignments, quizzes), any return format expectations, or whether the list is paginated. Given the low complexity, a slightly richer description would enhance 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?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no extra meaning about the parameters, but the schema already provides sufficient details for the two required IDs.
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 'List all items in a module' clearly states the action (list) and the resource (items in a module). It distinguishes from sibling tool 'list_modules' by specifying items rather than modules, but does not explicitly call out this distinction or elaborate on what constitutes an item.
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 provided on when to use this tool versus alternatives. The description does not mention any preconditions, exclusions, or related tools such as 'list_modules' or 'add_module_item'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It accurately states the action (list), the scope (per assignment), and output fields (student name, score, status, timestamp), but omits details such as pagination, sorting, filtering, or authorization requirements. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences, front-loaded with the primary action and resource, followed by the specific output fields. No redundant information or fluff.
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?
With no output schema and no annotations, the description partially compensates by listing some returned fields, but it omits potential additional fields (e.g., submission ID, user ID), pagination behavior, or edge cases like deleted users. For a simple list tool, it is adequate but leaves room for improvement in 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?
All three parameters have descriptions in the schema, providing 100% coverage. The tool description adds no new information about parameters beyond the schema, aside from implicitly confirming the assignment_id works for linked submissions, which is already stated. Baseline 3 applies since schema does the heavy lifting.
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 identifies the tool's purpose as listing submissions for an assignment, scoped to course and assignment, and specifies the returned fields. It differentiates itself from course- or user-level submission tools by mentioning graded discussions and New Quizzes, though it doesn't explicitly name 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like download_submissions, submission_summary, or list_missing_submissions. The description only implies usage for listing submissions, with no exclusion criteria or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention important side effects such as whether a graded discussion also creates an assignment, default publication state (unpublished is implied by the 'published' parameter default), or any permission requirements. The description only restates the basic action without behavioral nuance.
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 front-loads the core action and resource. There is no wasted verbiage, and it is appropriately sized for a tool with well-covered parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no annotations, and no output schema, the description is far too minimal to be contextually complete. It omits key details such as what happens when points_possible is set (graded discussion assignment creation), default states, and what the response would contain. The schema compensates for parameter details but not for behavioral or return-value context.
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 high (90%), so the schema already documents parameters thoroughly. The description does add a small semantic cue ('graded or ungraded') that maps to points_possible, but this is also covered by the parameter description. No significant additional meaning is provided 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 clearly states the action ('Create') and the resource ('a new graded or ungraded discussion topic'), distinguishing it from related tools like update_discussion or list_discussions. The verb+resource structure 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when creating a new discussion topic, but it does not explicitly state when to use it versus alternatives (e.g., create_assignment for graded work). No exclusions or comparative guidance are provided, so usage context is only inferred from the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and filters, omitting details such as pagination, sorting, default date ranges, inclusion of assignments by default, or response format, leaving significant behavioral aspects undisclosed.
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 that efficiently conveys the core functionality and optional filters, with no unnecessary words or repetition.
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 and full schema coverage, the description is minimally adequate. However, it does not explain response shape, pagination, or how the type filter relates to other listing tools, leaving some contextual gaps for an agent to infer.
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 all four parameters, so the baseline is 3. The description's mention of filtering by course, date range, or type maps to the properties but adds no additional semantics or syntax details 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 clearly states the action ('List calendar events') and the resource, and it mentions optional filters, making the purpose specific and easily distinguishable from the sibling create/update/delete calendar event tools.
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 that this tool is for retrieving calendar events and can be filtered, but it does not provide explicit when-to-use vs alternatives, exclusions, or comparisons to similar list tools like list_assignments. The usage guidance is implicit rather than 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?
With no annotations provided, the description carries the full burden. The verb 'Get' implies a read-only operation with no side effects, which is helpful, but it does not disclose other behavioral traits such as authentication requirements, rate limits, output format, or any constraints on date range. The description is adequate but lacks depth.
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 action, resource, and scope. There is no redundant language or clutter, making it highly efficient 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 simple read-only tool with two well-described parameters and no output schema, the description gives a clear enough purpose. It mentions the 'hourly page view breakdown' which hints at the return shape, though it does not specify the exact format. Given the simplicity, this is nearly 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 course_id and student_id having clear descriptions. The description adds no additional meaning beyond restating what the schema already provides ('for a specific student in a course'). This meets the baseline but does not exceed 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 action ('Get'), the resource ('hourly page view breakdown'), and the scope ('for a specific student in a course'). It effectively distinguishes itself from siblings like get_course_activity (course-level) and get_student_assignment_data (assignment data) by specifying the exact granularity.
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 any prerequisites, limitations, or exclusions. Without such context, an agent might be unsure whether to call this or get_course_activity or get_student_summaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read/list operation, but does not explicitly state safety (read-only) characteristics, potential side effects, or response format. The optional include_students behavior is mentioned, which adds some transparency, but it is already evident from the schema. This is an adequate but not enriched disclosure.
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 action. It is front-loaded, contains no filler, and every word earns its place. The optional clause adds important nuance without bloating the text.
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 only 2 well-documented parameters and no output schema, the description provides sufficient context. It clearly states what the tool returns (sections) and the optional enrollments. While it lacks details on pagination or response structure, these are less critical for a basic list use case, making the description adequately 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?
The input schema already provides full descriptions of both parameters (course_id and include_students), so coverage is 100%. The description merely reiterates the include_students option without adding new meaning. Baseline of 3 is appropriate since 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 clearly states the tool's function with a specific verb ('List') and resource ('sections in a course'), and it distinguishes from siblings like list_students or list_courses by focusing on sections. The optional include_students detail adds useful specificity without ambiguity.
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 provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools such as list_students or list_courses. The intended context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It honestly discloses a key limitation (cannot update dates/points) but does not mention whether updates overwrite existing values, whether the operation is atomic, or any permission prerequisites. Additionally, the inclusion of 'title' misleadingly implies a capability that is not backed by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and scope, and includes an explicit alternative in the second sentence. Every word earns its place, with no filler.
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 this is a batch mutation tool with a nested updates object and no output schema or annotations, the description does not explain the structure of the updates object, error handling, atomicity, or return behavior. It covers key limitations and the alternative tool, but more context would be needed for an agent to confidently invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantics by listing updatable fields and excluding dates/points, but it mentions 'title' which is not in the schema and omits the 'discussion_type' parameter that is present. Schema coverage is 67%, and the description does not fully compensate for the undocumented 'updates' object, instead introducing an inaccuracy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and identifies the resource ('multiple discussions') and fields ('title/message/published'), clearly distinguishing it from siblings like batch_update_dates. However, it says 'title' is updatable though the schema does not include a 'title' property, which slightly muddies the purpose.
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?
It explicitly states when not to use this tool ('Cannot update dates or points') and names the exact alternative ('use batch_update_dates with assignment_ids'), providing clear when-to-use and when-not-to-use guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains the purpose but does not mention runtime behavior such as conflict handling, whether existing overrides are replaced, permission requirements, or the return value. The only implied behavior is 'create,' which is evident from the name.
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 the first sentence front-loading the core purpose and the second providing a concrete use case. No redundant information.
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 complexity (7 parameters, no annotations, no output schema), the description provides the key use case and the core distinction between section and student overrides. However, it lacks information about return values, conflict behavior, or edge cases. It's adequate but with clear gaps.
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 all 7 parameters described in the schema. The description adds context around the section/student distinction (mentioning 'section or set of students') but does not clarify additional parameter semantics beyond what the schema already states. Thus a 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 'Create a new date override for a specific section or set of students on an assignment,' which precisely identifies the verb, resource, and scope. It also provides an example use case that differentiates it from update/list siblings.
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 includes a clear when-to-use context: 'Use this to set section-specific due dates (e.g., different block start times for different sections).' It lacks explicit mention of alternatives or exclusions relative to update_assignment_override or batch_update_dates, so it falls short of an explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only says 'Create a new module,' which implies mutation but does not mention permissions, side effects, idempotency, or error conditions. The hint to list modules first is the only extra context, but it is not a disclosure of tool behavior.
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-loaded with the primary action. The second sentence provides a helpful tip without wasting words. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally adequate for a create operation with a rich schema. It lacks details about return values, permission requirements, or what happens when optional fields like position or unlock_at are omitted. The absence of annotations and output schema raises the need for more context, but the tool is simple enough that this may be the minimum viable.
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 all parameters are already documented in the schema. The description adds no parameter-specific meaning beyond the schema, which is acceptable per the baseline of 3. It does not confuse or restate what the schema already provides.
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: 'Create a new module in a course.' This clearly distinguishes it from sibling tools like update_module, delete_module, and list_modules. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable guidance: 'Use list_modules to see existing modules first.' This suggests a proper workflow and helps avoid duplicates, though it does not explicitly contrast with update_module or other alternatives. Still, it provides useful context for when 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?
The description discloses that the action 'cannot be undone,' which is crucial behavioral context beyond the simple verb 'delete.' However, with no annotations provided, it doesn't disclose other potential effects like cascading impacts on student grades or quiz availability, leaving some behavioral uncertainty.
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 short sentences, front-loaded with the action and resource, and the warning 'This cannot be undone' is placed prominently. Every word contributes, making it highly efficient.
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 delete tool with full schema coverage, the description covers the essential purpose and irreversibility. However, it omits details such as whether the deletion requires specific permissions, whether the quiz must be unpublished, and what happens to student submissions, leaving some gaps for an agent.
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 full descriptions for all three parameters (item_id, course_id, assignment_id), covering 100% of the schema. The description adds no additional parameter semantics beyond what the schema already contains, so the baseline score 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 uses the specific verb 'Delete' and identifies the resource as 'a question (item) from a New Quiz,' clearly distinguishing it from sibling tools like delete_assignment or delete_module_item. It is concise 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting questions from New Quizzes, but it doesn't explicitly state when to choose this over alternatives or mention any prerequisites like quiz permissions. No exclusions are given, such as 'do not use for classic quizzes.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It states the core action but doesn't disclose side effects, reversibility, permission requirements, or what exactly happens to student visibility (e.g., do they see grades in gradebook? Are comments hidden?). This leaves significant behavioral uncertainty.
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 short sentences, front-loaded with the primary action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a complete schema, but the lack of annotations and behavioral depth means the description doesn't fully prepare the agent for side effects or alternatives. It is adequate for basic invocation but not comprehensive.
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?
All three parameters have descriptions in the schema (100% coverage), so the schema already documents them. The description adds only the optional 'specific students only' nuance, aligning with only_student_ids, but no additional syntax or format details.
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 'hide' with a clear resource ('grades from students for an assignment') and notes the optional scoping to specific students. This distinguishes it from sibling tools like post_grades or grade_submission.
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 the use case (hiding grades) and mentions the optional 'for specific students only' nuance. However, it does not explicitly state when to choose this tool over alternatives like post_grades, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only states 'Update dates' and gives no information about permissions, side effects, or reversibility. It does not clarify that empty strings clear dates (though the schema does), and it doesn't warn about destructive implications. This is a minimal disclosure for a mutation 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?
The description is two sentences, directly front-loaded with the action and resource, followed by a precise prerequisite. Every word earns its place; no wasted text.
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 mutation with a well-covered schema, the description is adequate but not rich: it states the action, scope, and prerequisite. However, given no annotations or output schema, it leaves out behavioral context such as whether the update is partial or full replacement, and what happens on success. It also doesn't mention alternatives for batch or assignment-level updates.
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 all six parameters with 100% coverage, so the baseline is 3. The description adds no additional parameter meaning beyond the generic term 'dates', and it doesn't clarify which parameters are dates. Thus, no extra 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 clearly states the tool updates dates on a single section/student override, using a specific verb ('Update') and resource ('override'). It distinguishes from sibling tools by the 'single' qualifier and the reference to sections/students, and also differs from assignment-level date updates.
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 directs the user to call list_assignment_overrides first to obtain the override ID, providing a clear prerequisite. It implies the tool is for single overrides but does not mention when not to use it or alternatives like batch_update_dates or update_assignment_dates.
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 discloses that it returns the created quiz object including assignment_id, which is helpful. However, there are no annotations, so the description must carry the full burden of behavioral disclosure. It doesn't mention permissions, reversibility, or side effects beyond returning a quiz. The 'Create' action implies mutation, but specific traits are limited.
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, direct and efficient. It immediately states the purpose and the key return information without 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 create tool with 6 parameters and no annotations, the description is fairly complete. It specifies the return value, identifies Quizzes.Next, and the schema covers parameters. However, it lacks explanation of prerequisites or default behaviors (like whether unpublished quizzes are created by default), which would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for parameters, so the schema already provides all parameter descriptions. The tool's description adds no additional parameter semantics—it only mentions the return value. Thus, 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?
Clearly states the action (Create), the resource (a New Quiz in Quizzes.Next), and context (in a course). This distinguishes it from create_assignment and create_quiz_item, and the mention of Quizzes.Next differentiates from any classic quiz tools.
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 a clear indication of what the tool does, but no explicit guidance on when to use it versus alternatives like create_assignment or update_new_quiz. It implies use when creating a new quiz in Quizzes.Next, but doesn't explicitly exclude other scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing destructive behavior. The word 'permanently' indicates irreversibility, which is useful. However, it does not mention potential side effects, permission requirements, or the confirm_title safety mechanism beyond what the schema provides.
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 that states the core function efficiently. Every word earns its place, and there is no 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 delete tool with two fully documented parameters, the description is nearly complete. It provides the essential permanence warning. The lack of annotations is offset by the clarity of the description and schema. No output schema is needed for a delete 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 covers 100% of parameters with descriptions (event_id and confirm_title), so the baseline is 3. The description adds no further parameter meaning 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 clearly states the action ('delete') and the resource ('calendar event'), and the modifier 'permanently' adds important specificity. It distinguishes itself from sibling tools like create_calendar_event and update_calendar_event.
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: use this tool to delete an existing event. However, there is no explicit guidance on when not to use it or alternatives, such as using update_calendar_event to modify instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses key side effects: creates folders per student and returns the saved path. It does not mention permissions, overwrite behavior, error handling, or what happens if there are no submissions, but it provides more than a mere action statement.
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. It is front-loaded with the primary action and quickly covers side effects and return value. Every sentence adds value.
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 three parameters and no output schema, the description covers the main action, the side effect (folder per student), and the return value (path). It is largely complete, though it could benefit from a note about required parameters, but the schema covers those.
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% (all three parameters have descriptions). The tool description adds no additional parameter-level meaning beyond what the schema already provides, so 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 verb (Download), resource (submitted files for an assignment), and outcome (save to a local directory, create folder per student, return path). It is specific enough to distinguish from sibling tools like list_submissions or grade_submission.
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 context of when to use is implied: for downloading assignment submissions. However, it does not explicitly mention alternatives like list_submissions for inspecting submissions or download_discussion_entries, nor does it state when not to use the tool. No exclusions or preconditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. The verb 'Get' implies a read-only operation, and it adds that the result includes description/instructions. However, it does not disclose any potential side effects, auth requirements, or response structure, which is a moderate gap given zero annotation coverage.
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 that conveys the core purpose and a key detail (description/instructions) with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with full schema coverage and no output schema, the description gives a clear sense of what to expect ('full details' including description/instructions). It is slightly generic but sufficient given the low complexity.
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 course_id and assignment_id well described. The description adds no extra meaning about parameters, so the baseline of 3 is appropriate since the schema already documents them fully.
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's function: 'Get full details of a single assignment' with a specific verb and resource. It distinguishes itself from sibling tools like list_assignments by focusing on a single assignment retrieval.
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 when you need details for one specific assignment, but it does not explicitly state when not to use it versus alternatives like list_assignments. No exclusionary or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful context beyond the tool name by specifying 'including its message/instructions,' which clarifies a key return component. However, it does not disclose potential response formatting, authentication requirements, or edge cases, making it adequate but minimal for a read operation.
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 that states the verb and resource immediately, with no redundant wording. It is appropriately sized for the tool's simplicity and earns its place fully.
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 get operation with no output schema, the description covers what the tool does and adds the key detail that message/instructions are included. It could further clarify what 'full details' encompasses, but given the low complexity and complete schema, 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?
The input schema fully describes both parameters (course_id and discussion_id) with clear descriptions, so the baseline is 3. The tool description does not add any parameter-level meaning beyond the schema, but it also does not need to since the schema is self-sufficient.
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' and identifies the resource as 'a discussion topic' with the clarifying detail 'full details... including its message/instructions.' This clearly distinguishes it from sibling tools like list_discussions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get full details' implies this is for retrieving a single discussion topic when a complete picture is needed, as opposed to a list. However, it does not explicitly name alternatives like list_discussions or state when a user should choose this tool over others, leaving usage context implied rather than 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?
With no annotations provided, the description carries the full burden. It discloses the returned data scope (interaction_data, scoring_data, feedback) and implies a read-only operation via 'Get'. However, it does not mention potential error conditions, prerequisites, or permissions, which are gaps for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 verb and resource, and includes specific data fields without extra wording.
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 tool with only 3 parameters and no output schema, the description adequately conveys the purpose and return scope. It does not explain what interaction_data or scoring_data contain, but given its simplicity, the description is sufficiently 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 coverage is 100%, so parameter descriptions already fully document item_id, course_id, and assignment_id. The tool description adds context about return data but does not enhance understanding of parameter semantics beyond what the schema provides, matching the high-coverage baseline.
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 'full details of a single quiz item', and explicitly lists included data fields (interaction_data, scoring_data, feedback). This distinguishes it from sibling tools like list_quiz_items (listing) and create/update/delete_quiz_item (mutations).
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 context ('full details' vs listing) but does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks clear comparison with list_quiz_items or get_new_quiz, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that grading overwrites the existing grade, whether the comment replaces prior comments, or any permission or irreversibility implications. The note about assignment types is helpful but does not cover the mutation's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence earns its place. It is concise without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema, so the description must explain what to expect on invocation. It does not mention return values, error conditions, or side effects beyond the action itself. While it covers usage context, it is incomplete for an agent needing to know what happens after grading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, with each parameter well-described, so the baseline is 3. The description adds no extra parameter meaning beyond the schema, aside from restating that a score and optional comment are involved, which is already in 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 specific verb (grade) and resource (single student submission) with clear scope (score and optional comment). It also distinguishes from the sibling tool grade_with_rubric, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool versus grade_with_rubric, and clarifies it applies to regular assignments, graded discussions, and New Quizzes. This provides clear context and an exclusionary alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It specifies what the tool sets (extra time, extra attempts) but fails to disclose whether accommodations are additive or overwrite existing ones, what permissions are required, or what happens if optional parameters are omitted. This is a significant transparency gap for a mutation 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?
The description is two sentences, front-loaded with the action and scope, and contains no unnecessary words. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a clear purpose, the description leaves important contextual details unresolved: whether the tool merges or replaces existing accommodations, the behavior when optional parameters are not supplied, and any prerequisites beyond knowing student IDs. With no output schema and no annotations, this is a notable completeness gap.
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 baseline is 3. The description adds value by naming the accommodation types (extra time, extra attempts) and by cross-referencing list_students for obtaining student_ids, which goes beyond what the schema provides.
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's purpose: setting testing accommodations (extra time, extra attempts) for specific students on a New Quiz. The verb 'Set' and the specific resource 'testing accommodations' distinguish it from sibling tools that manage quiz content or general quiz settings.
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 practical usage guidance by directing users to list_students to find student user IDs. However, it does not explicitly state when not to use this tool or mention alternatives for general quiz settings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait of partial update (unspecified fields remain unchanged) via 'Only include fields you want to change.' However, it does not disclose any other behavioral aspects like auth requirements, error behavior, or side effects, which are important for a mutation 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?
The description is two short sentences, both essential. It states the action and the key usage rule without any fluff, making it easy to parse and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a 6-parameter mutation tool with no annotations and no output schema. It lacks details about the relationship between course_id and module_id, error conditions, what happens on success, and how this tool relates to publish_module (which also has a published field). The partial-update hint is useful but leaves many operational questions unanswered.
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 50%, and the description adds the crucial semantic that all optional fields are optional update targets, not required inputs. This partially compensates for undocumented fields like 'name', 'position', and 'published'. However, the description does not explain the meaning of these fields or their formats beyond what the schema already provides, so it doesn't fully compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Update an existing module.' This distinguishes it from sibling tools like create_module, delete_module, and publish_module. The additional phrase 'Only include fields you want to change' further clarifies that this is a partial-update operation.
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 establishes clear context: use this when updating an existing module, and only include fields to change. However, it does not explicitly mention alternatives (e.g., publish_module for publishing, create_module for new modules) or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action without revealing side effects such as overwriting existing associations, implications of use_for_grading (default true), or required permissions. This is a significant gap for a mutating 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?
Three short sentences: action, use case, and helper guidance. Each sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose and prerequisite workflow, but with 7 parameters and no output schema, it omits behavioral outcomes (e.g., association replacement) and does not clarify optional flags such as hide_points or use_for_grading. It is minimally complete for basic selection but lacks depth.
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 parameters are well documented. The description adds a useful pointer to list_rubrics for locating rubric_id, which is meaningful extra guidance beyond the schema. No deeper elaboration is needed given the high 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's action: associating an existing rubric with one or more assignments. It also provides the use case 'reuse a rubric across multiple assignments,' distinguishing it from rubric creation or editing tools like create_rubric or update_rubric.
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 a clear when-to-use context: 'This is how you reuse a rubric across multiple assignments' and directs users to list_rubrics to find rubric_id. It lacks explicit exclusions or alternatives, but the context is sufficient relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses asynchronous behavior and a Progress object return, which is valuable. However, it omits details about permissions, side effects, and error handling, leaving gaps for a mutation 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?
The description is two concise sentences with purpose first, then async behavior. Both sentences add critical information and there is zero wasted text.
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 tool with no output schema and no annotations, the description covers purpose and async behavior but lacks guidance on when to use, prerequisites, or failure handling. It is minimally adequate but not complete for a mutating bulk 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%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, but the schema already thoroughly documents each parameter, including acceptable score formats.
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 grades multiple students on one assignment at once, using specific verb 'Grade' and resource 'multiple students on one assignment'. This distinguishes it from sibling tools like grade_submission and grade_with_rubric by emphasizing bulk operation.
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 'at once' clarifies the bulk nature, implying use when grading multiple students simultaneously. While it does not explicitly name alternatives or exclusions, the context is clear enough relative to single-grading siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses conditional grade availability ('including grades if available') and the grading period behavior, which is valuable. But it does not describe the return shape (single object vs. list), possible additional fields, or error/permission implications, leaving room for agent uncertainty.
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: the first states the core purpose, the second covers the optional grading period nuance. It is front-loaded, scannable, and contains no filler or redundant repetition.
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 tool with no output schema and no annotations, the description provides the essential purpose and grading period nuance, but it does not specify whether the response is a record or list, what 'enrollment details' include, or how missing grades are represented. This ambiguity could hinder correct invocation and output interpretation.
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% parameter coverage, including a detailed explanation of grading_period_id. The tool description largely restates that parameter's behavior and adds the phrase 'cumulative lifetime grade,' but does not add substantial new semantics 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 clearly states the action ('Get') and resource ('enrollment details for a specific student in a course'), and clarifies optional grade scoping. It distinguishes this from sibling tools like get_student_summaries or get_student_activity by focusing on enrollment-specific details for a single student/course.
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 specific guidance for the grading_period_id parameter, explaining when to use it (semester/term grade vs. cumulative) and explicitly recommending list_grading_periods to find ids. However, it does not explicitly contrast this tool with other student-data tools or state when to prefer it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It implies a read-only operation (listing) but doesn't explain what counts as 'missing' (e.g., excused assignments, due date windows) or any side effects. This is adequate but lacks rich 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 two sentences with no fluff. The first sentence states the function; the second adds practical context. Every word earns its place.
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?
With three parameters and no output schema, the description is relatively complete but doesn't define what 'missing' means or how the output is structured. It's enough for a simple list tool, but some ambiguity remains.
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 parameters are already well-documented. The description doesn't add extra meaning beyond the schema—it says 'for a specific student' which matches student_id, but adds no additional syntax or semantics.
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's function: 'List all missing assignments for a specific student.' It specifies the verb (list), the resource (missing assignments), and the scope (specific student). This distinguishes it from siblings like list_submissions or get_student_assignment_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Very useful for parent conferences and progress reports.' While it doesn't explicitly mention alternatives or exclusions, the intended scenarios are clear and help an agent decide when 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the update is partial ('Only include fields you want to change') but does not disclose additional behaviors such as whether omitted fields are preserved, permission requirements, idempotency, or error conditions. This is a meaningful gap for a mutation 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?
The description is two sentences, front-loaded with the core action, and every word adds value. The second sentence provides crucial usage guidance without padding.
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 relatively simple (6 flat parameters, no nested objects), and the description covers purpose and partial-update semantics. However, it lacks any mention of return values, error scenarios, or permission requirements, which would be expected for a mutation tool. With no output schema, the description leaves some gaps for the agent.
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 schema already describes several parameters (e.g., ISO 8601 for times, HTML for description), but the description adds critical semantics: it clarifies that event_id is the only required field and that all other fields are optional, representing a partial update. This goes beyond the raw schema by explaining the update model, which compensates for the ~33% of parameters without schema descriptions.
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 action ('Update') and the resource ('an existing calendar event'), distinguishing it from create/delete siblings. The additional note 'Only include fields you want to change' specifies the partial-update behavior, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing event and warns that only changed fields should be included, which guides the caller on the intended use. It does not explicitly mention alternatives like create/delete, but the sibling names make the distinction obvious, and the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Update a New Quiz's settings' without mentioning permissions, whether changes are reversible, potential side effects, or the response format. The note that 'New Quizzes are assignments' is contextual but not behavioral. This is a significant gap for a mutation 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?
The description is exactly two sentences: the first states the core purpose with examples, the second provides a critical usage distinction. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 11 parameters, no annotations, and no output schema, the description provides the core scope and an essential alternative for date changes. However, it does not explain the outcome of an update (e.g., response structure, whether existing settings are replaced) or any prerequisites. It is adequate but leaves some gaps.
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 all 11 parameters. The description's examples (time limit, shuffle, attempts) map to existing schema properties but add no new meaning beyond what the schema already states. Baseline 3 is appropriate when 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 clearly states the tool's purpose: 'Update a New Quiz's settings' with specific examples (time limit, shuffle, attempts). It also distinguishes itself from sibling tool update_assignment_dates by specifying when to use that alternative for date changes. This is a specific verb+resource with clear scope.
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 provides explicit usage guidance: for date changes (due_at, unlock_at, lock_at), use update_assignment_dates with the assignment_id instead. This names an alternative tool and the specific condition when to use it, which is exactly the kind of when/when-not guidance the rubric rewards.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states 'This cannot be undone', effectively warning about irreversibility. This is a critical safety-relevant trait for a destructive tool, though it does not elaborate on other effects like cascading deletions.
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 no filler. 'Permanently delete an assignment' states the action, and 'This cannot be undone' adds necessary warning, both earning their place 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 delete tool with full schema coverage and no output schema, the description covers the essential behavioral context: permanence and irreversibility. It doesn't mention the confirm_name safety check, but the schema documents that. Overall, the context is sufficient for an agent to select and invoke the tool 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 input schema has 100% description coverage for all three parameters (course_id, assignment_id, confirm_name), each with clear definitions. The description adds no additional parameter-level meaning, so 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 states 'Permanently delete an assignment' with a specific verb and resource, and 'permanently' adds crucial scope, distinguishing it from update_assignment or other assignment operations. Among sibling delete tools, its target is clearly assignments, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when deletion is intended but provides no explicit when-to-use or alternative guidance. It relies on the verb 'delete' and the permanence note to convey context, but does not mention alternatives like update_assignment or the safety confirm_name step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does disclose a key non-destructive trait (does not delete underlying content), but it omits other important behavioral details such as irreversibility, permission requirements, or the confirm_title safety check. This is useful but incomplete behavioral transparency.
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 and front-loaded with the primary action. The second sentence adds crucial clarifying context without any fluff. Every word earns its place, making it highly concise 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?
Given the low operational complexity (a simple delete operation), full schema coverage, and no output schema, the description is largely complete. It clearly states the core action and the key distinction from module deletion. The only minor gap is not mentioning the confirmation mechanism, but this is already documented in the schema, so the description is 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 input schema provides 100% coverage with descriptions for all four required parameters. The description adds no additional parameter semantics—it does not elaborate on how to obtain item_id, how confirm_title works, or any parameter-specific nuances. Thus, the description adds no value beyond the schema, which is already comprehensive.
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's purpose with a specific verb and resource: 'Remove an item from a module.' It further distinguishes itself from sibling tools like delete_module by explicitly clarifying that it 'only removes the module entry — the underlying assignment/page/file is not deleted.' This makes the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it says the tool only removes the module entry, not the underlying content, which implies when to use it (to unlink an item) and when not to use it (to delete underlying content). However, it does not explicitly name alternative tools or provide a direct 'use X instead' recommendation, so it falls short of 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?
No annotations are provided, so the description carries the full burden. It discloses the key asynchronous behavior: returns a progress object and requires polling a URL. This is valuable context beyond the schema. However, it does not mention potential side effects, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and followed by a key behavioral note. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential flow: generation of a report and the polling mechanism. Given the simple parameter set and full schema coverage, it is reasonably complete. Minor omission: no explicit detail about the progress object's contents beyond 'URL', but the implication is clear.
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 documents all four parameters with descriptions and enums. The description adds no extra parameter semantics beyond what the schema provides, matching the baseline.
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 (Generate) and names the exact resource (student analysis or item analysis report for a New Quiz). It clearly distinguishes from sibling tools like get_student_summaries or analytics by specifying report types and 'New Quiz'.
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 the tool (when a downloadable report file is needed), but no explicit guidance is given about alternatives or when not to use it. The description lacks exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are chronological and limited to dated items, which is useful. However, it omits details about return format, pagination, or whether all statuses are included, leaving some behavioral ambiguity.
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-loaded with the verb and purpose, and contains no redundant or filler language. Every word adds value.
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 required parameter) and no output schema, the description sufficiently explains what the tool does and when to use it. It could be more explicit about the returned fields, but the overview nature is implied well enough for selection and 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 already defines course_id as 'Canvas course ID' with 100% coverage, so the description does not need to add parameter details. It adds no extra semantics beyond the schema, 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 uses a specific verb 'get' and clearly identifies the resource as a chronological overview of assignments, discussions, and quizzes in a course. This distinguishes it from sibling tools like list_calendar_events or list_assignments, which focus on single 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'useful for understanding the current schedule before making changes,' providing clear context for when to use it. However, it does not explicitly name alternatives or state when not to use it, but the guidance is sufficiently 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' implies a read-only operation, and the listed content adds context, but permission requirements, error behavior, and return format are not addressed.
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 no redundancy. The purpose is front-loaded, and the second sentence provides actionable parameter guidance without unnecessary 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?
With no output schema and no annotations, the description covers the tool's scope and key fields (settings, time limits, configuration) and gives parameter discovery guidance. It lacks return structure or error semantics, but for a straightforward getter with high schema coverage, it is sufficiently complete.
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%, providing a baseline of 3. The description adds valuable meaning for assignment_id by explaining it is a Canvas assignment ID discoverable via list_new_quizzes or list_assignments with is_quiz_lti_assignment=true, exceeding the minimal schema 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 clearly states the verb 'Get' and the resource 'full details of a single New Quiz', specifying Quizzes.Next and the included content (settings, time limits, configuration). This distinguishes it from sibling tools like get_assignment and get_quiz_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance for finding assignment_id via list_new_quizzes or list_assignments, but does not explicitly state when to prefer this tool over siblings such as get_assignment or get_quiz_item. Usage context is implied rather than 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?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions returned fields (name, email, bio) but doesn't explicitly state read-only behavior, permission requirements, or possible error cases. However, the word 'Get' strongly implies a read operation, and the listed fields provide some 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, well-structured sentence that conveys purpose and scope without any wasted words 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?
The tool has a single parameter and no output schema, so the description's listing of returned fields (name, email, bio) provides adequate coverage. It doesn't exhaustively document the full profile schema, but 'including' suggests more fields exist, which is acceptable for a simple lookup 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 100%, with user_id described as 'Canvas user ID'. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. It's sufficient but not enhanced.
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's function: 'Get any user's profile information including name, email, and bio.' It specifies a distinct resource (user profiles) and distinguishes itself from sibling tools that target course-specific data or student analytics.
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?
Description indicates broad applicability ('Works for students, teachers, and any Canvas user'), giving clear context for when to use. It doesn't explicitly mention alternatives or exclusions, but the 'any user' framing implicitly separates it from student-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It discloses that the tool returns group weights and that IDs are usable for assignment creation/updates, but it does not mention pagination, authentication, or any limitations. The 'List' verb implies read-only, but without explicit statement, the transparency is adequate but not thorough.
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 no fluff. It front-loads the purpose and includes a key usage note, making every sentence 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 1-parameter tool with no output schema, the description conveys the essential information: what is listed, that weights are included, and how the IDs are used. It lacks explicit detail on the exact return fields, but given the simplicity and purpose, it is nearly 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?
The schema description covers 100% of the parameters (course_id as 'Canvas course ID'), so the description does not need to add param details. The baseline of 3 applies because the schema already documents the parameter, and the description offers no additional semantic value for 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 'List' and the resource 'assignment groups (grading categories) in a course with their weights', distinguishing it from sibling tools like list_assignments. It also explains the downstream use case (returned IDs used as assignment_group_id), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by noting that the returned group IDs are used when creating or updating assignments. However, it does not explicitly mention alternatives or situations where this tool should not be used, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'List' implies a non-destructive read operation, but the description does not disclose return format, pagination, or any edge-case behaviors. It adds detail on override types (section/student) but lacks richer 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?
Two concise sentences. The first states the action and resource, the second provides a practical use case. Every sentence earns its place with no filler 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?
Given the tool's simplicity (2 required parameters, no output schema), the description adequately covers the purpose and usage context. It mentions discovering override IDs, which hints at the return value. Minor gaps around pagination or response shape are not critical for this straightforward listing 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 input schema covers 100% of parameters with clear descriptions for course_id and assignment_id. The description adds no additional parameter syntax or format details 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 uses a specific verb 'List' with a clear resource 'date overrides' for an assignment, and specifies the scope (section-specific or student-specific). It distinguishes from siblings like update_assignment_override by framing this as the discovery step before updating.
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 states 'Use this to discover override IDs before updating them,' giving clear contextual guidance for when to invoke the tool. It implies an alternative action (updating) but does not name the exact sibling tool or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: graded discussions also appear as assignments with assignment_id. However, it does not mention pagination, ordering, or permission requirements, leaving some behavioral aspects unspecified for a read operation.
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-loaded with the primary purpose, and each sentence earns its place. The first sentence states what the tool does; the second adds valuable cross-references without fluff.
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 list tool with no output schema, the description provides essential context: it lists discussions, notes graded discussions also appear as assignments, and gives pointers for updating. It lacks explicit return field details beyond assignment_id, but the description is adequate 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%, so the baseline is 3. The description does not add additional parameter semantics beyond the schema; it merely references assignment_id in the response context, not explaining parameters like course_id or search_term further.
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 'list[s] discussion topics in a course', a specific verb+resource. It further distinguishes from siblings by noting graded discussions also appear as assignments with assignment_id, which is a unique detail not present in sibling tools like get_discussion or create_discussion.
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 directs users to update_assignment_dates or update_assignment for modifying graded discussions, providing clear alternatives for update operations. However, it does not explicitly mention when to use get_discussion for a single discussion, though the listing purpose 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?
No annotations are provided, so the description carries the full burden. It implies a read-only list operation and adds a usage hint, but does not disclose details like whether only students with submissions are returned, pagination, or any permissions. For a list tool this is acceptable 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 two sentences, front-loaded with the core purpose, and every sentence earns its place. The second sentence directly helps the agent use the output, with no redundant or vague 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?
Given the simple 2-parameter tool with no output schema, the description provides enough context: it names the assignment, mentions the returned IDs, and links to grading tools. It lacks details on returned student fields or inclusion criteria, but these are not critical for the minimal use case.
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 descriptions for both course_id and assignment_id with 100% coverage. The description does not add parameter-specific details beyond the schema, but the phrase 'for a specific assignment' reinforces the assignment_id purpose. This meets the baseline for high 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 action ('List students'), a clear resource ('who can be graded for a specific assignment'), and distinguishes from siblings like list_students by focusing on gradeable status. It also explicitly mentions the assignment context, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case by saying 'Use the returned IDs as student_id in grade_submission or grade_with_rubric', which indicates when this tool is relevant. However, it does not explicitly contrast it with alternatives like list_submissions or list_students, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation through 'List', but does not mention permissions, pagination, or response format. For a simple read tool, this is minimal but acceptable.
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 consists of two concise sentences: one stating the purpose and one providing alternatives. Each sentence earns its place with no unnecessary words 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 low-complexity read tool with full schema coverage, the description is adequate: it states what it does and points to related management tools. It does not explain return values, but no output schema exists and the tool's function is straightforward.
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 course_id and include_items both clearly described in the input schema. The description adds no parameter-specific meaning beyond what the schema already provides, so a 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 uses a specific verb ('List') and resource ('modules in a course'), clearly stating what the tool does. It also distinguishes itself from management tools by names and redirects to them, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to see create_module, update_module, add_module_item, and related tools for module management, serving as a clear when-not-to-use for those operations. However, it does not explicitly mention read alternatives like list_module_items, so there is a slight gap in complete usage 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the return fields (ID, title, point total, criteria count) and implies read-only behavior through 'List.' It does not mention pagination or rate limits, but for a simple listing tool this is adequate.
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 concise, front-loaded sentence that specifies action, scope, and return fields, with no wasted words or 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 single-parameter listing tool with no output schema, the description sufficiently covers purpose and return fields. It could add pagination or note that it returns the complete set, but these are not essential for understanding the tool's basic functionality.
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 only parameter, course_id, is already fully described in the schema as 'Canvas course ID' (100% coverage). The description adds no new semantic detail beyond the schema's own meaning.
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 ('all rubrics') and scope ('in a course'). It distinguishes itself from siblings like get_rubric (which fetches a single rubric) and create/delete/update_rubric (mutations).
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 clearly indicates the use case by saying 'List all rubrics in a course,' but it does not explicitly contrast with get_rubric or state when not to use it. No alternatives are named, so guidance is implied rather than 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the core side effect (grades become visible to students), which is a write/mutation operation. However, it does not disclose potential side effects, permissions required, reversibility, or what happens to already-posted grades. The description adds some value beyond the tool name but lacks depth about the operation's implications, making it adequate but with gaps.
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. The first sentence immediately establishes verb, object, and purpose. The second sentence introduces the optional behavior in a clear, front-loaded manner. There is no redundant information, and every word earns its place. This is exemplary 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?
Given the tool's simplicity (3 params, no output schema, no annotations), the description covers the essential aspects: what the tool does, the visible outcome, and the optional parameter behavior. It does not explain return values (likely none for a mutation) or prerequisites, but the description is sufficiently complete for an agent to correctly invoke the tool. It could optionally mention the opposite operation (hide_grades) or that it is a write operation, but those are not critical for basic usage.
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 description coverage is 100%, so each parameter is already described (course_id, assignment_id, only_student_ids). The description adds a brief summary of the optional parameter ('Optionally post for specific students only'), but this repeats the schema's own description for only_student_ids without adding new details. No additional syntax or format information is provided, so the description does not significantly 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?
The description clearly states the action ('Post' or 'make visible') and the resource ('grades for an assignment'). It also explains the purpose ('so students can see them') and distinguishes from the sibling tool 'hide_grades' by explicitly contrasting visibility. The optional behavior for specific students is also mentioned, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you want to make grades visible to students. It also gives a conditional usage ('Optionally post for specific students only'). However, it does not explicitly mention alternatives or exclusions, such as saying 'use hide_grades to reverse' or 'use this instead of the hide tool when you want to release grades'. The guidance is implied rather than explicit, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavior. It discloses the key side effect that the rubric is not deleted, but it does not mention other behavioral aspects such as permissions, error conditions, or idempotency. It is partially transparent but not fully 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 with no filler words. It is front-loaded with the action and ends with a clarifying constraint.
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 tool with no output schema, the description adequately states the purpose and the critical non-destructive side effect. It lacks explicit usage exclusions or more detailed behavior, but it is sufficient for a basic 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 input schema covers 100% of parameters with descriptions (course_id, assignment_id). The tool description does not add any new parameter semantics beyond the schema, so the baseline score 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 uses a specific verb+resource: 'Remove a rubric association from a specific assignment' and explicitly clarifies that it does not delete the rubric itself. This distinguishes it from sibling tools like delete_rubric, which deletes the rubric.
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 when to use it: when you need to detach a rubric from an assignment while preserving the rubric. The phrase 'without deleting the rubric itself' contrasts with delete_rubric, but it does not explicitly name alternatives or provide exclusions, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the update action and compatible object types, but does not mention potential side effects, whether unspecified date fields remain unchanged, permission requirements, or response format. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with relevant information: what the tool does, the scope, compatible object types, and a preference rule over a sibling. No filler or restatement of the name.
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 date-update tool, the description covers purpose, scope, applicable object types, and sibling distinction. It does not explain return values or error cases, but the absence of an output schema and the straightforward nature of the operation make the definition 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?
Schema description coverage is 100%, so baseline 3 applies. The description repeats the three date field names but doesn't add additional syntax, formatting, or clearing behavior beyond what the schema already documents. It adds marginal value by emphasizing the 'and/or' partial update nature, but the schema already communicates optionality.
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 ('Update due_at, unlock_at, and/or lock_at for a single assignment'), clearly naming the exact fields affected. It also distinguishes itself from the sibling update_assignment by focusing on dates and mentioning compatibility with graded discussions and New Quizzes.
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?
Explicit guidance is provided: 'Prefer this over update_assignment when you only need to change dates.' This tells the agent exactly when to select this tool over the closest alternative. The note that it works for graded discussions and New Quizzes broadens the context of appropriate use.
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?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It clearly states that deletion is permanent ('cannot be undone') and that it cascades to all items within the module. This covers the most critical behavioral traits. It does not mention permission requirements or whether confirmation is needed, but the schema already documents the confirm_name parameter.
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-loaded with the core action, and every word earns its place. It avoids redundancy and clearly communicates the primary behavior and the key consequence (permanence).
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 three-parameter deletion tool with 100% schema coverage and no output schema, the description sufficiently covers the tool's purpose, scope, and critical behavioral consequences. No additional details about return values are necessary, and the potential for cascading deletion is explicitly mentioned.
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 baseline is 3. The description does not add parameter-level details beyond what the schema already provides for course_id, module_id, and confirm_name. The confirm_name parameter is self-explanatory in the schema as a safety check, so full credit is given to 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 uses a specific verb ('delete') and identifies the exact resource ('a module') along with a critical scope detail ('and all items within it'). This clearly distinguishes it from the sibling tool delete_module_item, which only removes items within a module. The permanence warning further reinforces the purpose.
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 when to use this tool (when you want to delete an entire module and its contents), but it does not explicitly state when not to use it or mention the alternative delete_module_item for removing a single item without affecting the module. Usage guidance is implied rather than directly compared across 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?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the operation is permanent ('cannot be undone') and describes the side-effect of removing the rubric from all associated assignments. This is strong for a destructive tool, though it could mention other impacts like existing rubric assessments.
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-loaded with the verb and resource, and every word contributes meaning. No unnecessary information or 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 simple delete tool with complete schema and no output schema, the description covers purpose, permanence, and side effects adequately. It is sufficient for an agent to understand when and how to use 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?
The input schema fully documents all three parameters with descriptions, including the confirm_title safety check. The description does not add parameter-specific detail, but 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 states 'Permanently delete a rubric from a course' with a specific verb and resource, clearly indicating the tool's function. It distinguishes from sibling tools like delete_rubric_assessment and remove_rubric_from_assignment by noting it removes the rubric from all associated 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 intended usage is implied: use this tool when you need to permanently delete a rubric. However, it does not explicitly contrast with alternatives such as delete_rubric_assessment or remove_rubric_from_assignment, so the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool downloads the actual discussion content as a JSON file, but it does not mention file handling behaviors such as overwriting, directory creation, or output file naming conventions.
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 action, no filler. The second sentence adds a useful contrast without unnecessary detail.
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, but there is no output schema and no description of return values or file output structure. The description covers the core purpose and differentiation, but misses practical details like how output_dir is used or what the JSON contains.
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 67%: course_id and discussion_id have descriptions, but output_dir lacks a description and the description does not explain it. The description adds minimal parameter context beyond what schema already provides.
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: 'Download all entries/replies for a discussion topic as a JSON file'. It also explicitly distinguishes itself from a sibling tool ('Unlike list_submissions...'), making the purpose unmistakable.
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 contrasts with list_submissions, clarifying when to use this tool (for actual discussion content) versus when to use the alternative (for grading metadata). This gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core grading behavior and per-criterion scoring, but it does not mention potential side effects like overwriting existing grades, requiring a rubric association, or what is returned. The hint to use get_rubric appears only in the schema, not in the description, so the description adds limited 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 two sentences, front-loaded with the core purpose and followed by a concrete alternative. Every sentence earns its place with no redundant or promotional language.
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 moderate complexity (nested criterion_scores array, no output schema, no annotations), the description covers what it does and when to use it, but omits side effects, return values, and prerequisites such as the assignment having an associated rubric. The schema fills some gaps, but the overall context is not fully complete for an agent to invoke it confidently.
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 each parameter (course_id, assignment_id, student_id, criterion_scores) having a clear description, including the useful note about using get_rubric to find criterion IDs. The description adds no extra parameter meaning 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 clearly states the action ('Grade a student's submission') using a rubric and elaborates on the method ('Provide scores for each criterion'). It explicitly distinguishes from the sibling tool grade_submission, making its unique 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: 'For simple score-based grading without a rubric, use grade_submission instead.' This names the alternative tool and the condition under which it should be chosen, making the usage context 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns term id, name, and dates, and that it lists terms. However, it does not explain the workflow_state filtering behavior (active/deleted/all) or any default behavior, relying on the schema for that information. For a read-only list tool, 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 two sentences, front-loaded with the action, and every clause provides value: what it lists, what it returns, and how to use the result. No wasted words.
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 list tool with one optional parameter, no output schema, and no annotations, the description sufficiently explains the tool's purpose, return values, and downstream usage. It is complete enough for an agent to select and invoke the tool 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%, so the baseline is 3. The schema already describes the single parameter (workflow_state) with an enum and default. The description does not add further semantic detail about the parameter beyond pointing out that the returned id is useful for other tools, which is indirectly about the output, not the parameter itself.
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 action ('List enrollment terms') on a specific resource ('terms defined in the account'), specifies the return fields (id, name, start/end dates), and clearly differentiates this tool from siblings that handle courses, modules, or calendar events.
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 contextual usage by showing how the returned id is used in downstream tools ('list_term_courses or create_course'). It does not explicitly state when not to use it, but the purpose is self-evident and no alternative term-listing tool exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals type-dependent field requirements and the New Quiz vs Classic Quiz nuance, which is useful. However, it does not mention side effects, permission requirements, default positioning behavior, or what happens on invalid input, leaving notable gaps for a mutation 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?
The description is two sentences with no wasted words. It front-loads the primary purpose, then efficiently delivers the type-specific conditions and the New Quiz exception. 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 tool with 9 parameters and complex type-dependent behavior, the description covers the most critical distinctions (type requirements, New Quiz vs Classic Quiz) but omits specifics for the ExternalTool type and doesn't address default values or post-add behavior. The schema fills parameter gaps, and the description handles the conditional logic well, but full completeness is not achieved.
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 parameters are already well documented. The description adds value by clarifying conditional requirements across types (e.g., Page needs page_url, SubHeader needs title) and the special rule for New Quizzes, which is not present in the schema. This goes beyond the baseline.
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 opens with a specific verb+resource combination ('Add an item to a module'), which clearly distinguishes it from sibling tools like create_module, update_module_item, and delete_module_item. It also provides type-specific context that reinforces its purpose without ambiguity.
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 on when to use the tool (adding items to a module) and provides type-specific guidelines, including the important exclusion that New Quizzes must use type='Assignment' rather than type='Quiz'. It does not explicitly name alternative tools, but the conditional usage guidance effectively directs the agent on proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clarifies the scope (regular assignments only) but does not disclose behavioral traits such as default publication state, permission requirements, or side effects. It is not misleading, but lacks depth beyond the purpose statement.
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-loaded with the main purpose and followed by concise exclusions. Every word 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11 parameters, full schema coverage, and no output schema, the description provides sufficient context for a basic create operation. It explains the tool's scope and exclusions effectively, though it omits any mention of prerequisites or error behavior. This is acceptable, as the schema covers parameters.
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 baseline is 3. The description does not add meaning to individual parameters; it only points to alternative tools for other assignment types. The schema fully documents parameter meanings, so no deduction 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 creates a new regular assignment in a course, using a specific verb and resource. It explicitly distinguishes itself from sibling tools by directing graded discussions to create_discussion and New Quizzes to create_new_quiz.
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?
It provides explicit when-to-use guidance ('Create a new regular assignment in a course') and when-not-to-use guidance with named alternatives for graded discussions and New Quizzes. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clarifies that the event is not an assignment, but does not disclose other behaviors such as permissions required, whether the event appears on a public calendar, or effect on other systems. Basic creation semantics are implied but not expanded.
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-loaded with the core action and resource, with the differentiation note following naturally. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description covers the essential purpose, examples, and disambiguation from create_assignment. However, without annotations or output schema, it could add more about return value or side effects, but this is a minor 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?
The input schema provides 100% coverage with each parameter described. The description adds no parameter-specific meaning beyond the schema, so the baseline score 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 action ('Create'), the resource ('standalone calendar event'), and provides concrete examples (office hours, class sessions, review sessions). It explicitly differentiates from create_assignment, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool (for non-graded calendar events) and when not to, directing users to create_assignment for graded items with due dates. This directly addresses tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the creation behavior, optional immediate association with an assignment, and the non-obvious effect that linked criteria feed into outcome rollups. However, it doesn't mention permissions, idempotency, or return value details, leaving some gaps for a write operation.
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 the primary action. It uses four sentences to convey purpose, criteria shape, optional assignment association, and outcome linking, with no redundant phrases.
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 create operation with rich schema annotations, the description covers the essential inputs and noteworthy behavior (outcome rollups). It could mention the return value or whether associating with an assignment has grading implications, but the absence of an output schema and the schema's own descriptions mitigate this gap.
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 input schema already covers all parameters with descriptions (100% coverage), but the description adds meaning beyond the schema: it explains the structure of criteria as an array of objects with ratings, that assignment_id is for immediate association, and how learning_outcome_id influences outcome rollups. This enriches the agent's understanding of how to construct valid 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 opens with a specific verb+resource ('Create a new rubric in a course'), and then elaborates on the criteria and ratings structure. It clearly distinguishes this from sibling tools like update_rubric, list_rubrics, or associate_rubric by focusing on the creation action.
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 explains when to use this tool (to create a rubric), describes the required input structure, and provides a pointer to list_outcomes for finding learning outcome IDs. However, it doesn't explicitly contrast with alternative tools like associate_rubric for attaching an existing rubric to an assignment, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It clearly states the tool returns engagement metrics and implies read-only via 'Get', but it does not explicitly mention side effects, authorization, or rate limits. The clarification that it returns engagement metrics, not assignment data, adds behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no filler. Every sentence serves a purpose: purpose first, then clarification/alternative.
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 read-only analytics tool with no output schema, the description provides sufficient context to understand what the tool returns and what it does not. It could mention output format or date range, but it is adequate for tool selection.
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% (course_id is described as 'Canvas course ID'), and the description does not add extra parameter details. Baseline of 3 is appropriate since the schema already documents the only parameter.
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 ('Get daily page views and participation analytics for a course') and explicitly distinguishes itself from assignment data, making it clear what the tool does and how it differs from siblings like list_assignments.
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?
It explicitly states when not to use the tool ('not assignment data') and provides an alternative ('use list_assignments for assignment info'), giving the agent clear guidance on tool selection.
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?
With no annotations, the description carries the burden of behavior disclosure. It mentions access scope ('courses you have access to'), the return value (IDs), default filtering ('active courses by default'), and admin-only search behavior. This adds context beyond the schema, though it omits details like pagination or outcome shape beyond IDs.
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 focused sentences that succinctly cover purpose, core output, default behavior, and admin capability. Every clause adds value with no 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?
As a simple list tool with two optional parameters and no output schema, the description adequately covers the main use case and the critical return value (course IDs). It could benefit from mentioning pagination or additional fields returned, but these are not essential for basic 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?
The schema descriptions already cover both parameters (search_term: admin-only, enrollment_state: filter with default active). The description repeats these concepts without adding new semantic detail. Since schema coverage is 100%, 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 opens with 'List Canvas courses you have access to,' which is a specific verb+resource statement. It further clarifies its role by noting it 'Returns course IDs needed by all other tools,' distinguishing it from more specialized sibling tools like list_sections or list_terms.
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 a primary use case: fetch course IDs before using other tools. It also provides conditional guidance for admins wanting to search all courses. However, it does not explicitly name alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields (ID, position, points, question type, content) and the New Quiz-only limitation, providing useful behavioral context beyond the schema. It does not mention pagination or error behavior, but for a simple list operation it is reasonably transparent.
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 core purpose, followed by a scope caveat and return details. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two well-documented parameters and no output schema, the description covers purpose, scope, and return contents. It lacks pagination/ordering details but is otherwise adequate, so not perfect but above minimal.
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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for course_id and assignment_id. No extra syntax, formats, or constraints are described.
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 'List all items (questions) in a New Quiz', using a specific verb and resource. It further distinguishes from Classic Quizzes and indicates the scope (all items), which differentiates it from sibling tools like get_quiz_item.
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 explicitly states the tool is for New Quizzes only and that Classic Quizzes do not have a question API, providing a clear exclusion. However, it does not name alternatives like get_quiz_item for fetching a single item, so it falls short of a full 5.
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?
There are no annotations, so the description must disclose behavior. It reveals the output is simpler than list_students, but does not detail pagination, response format, authentication needs, or any side effects. The added context is useful but incomplete.
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 no filler. The first sentence states the purpose, the second gives usage guidance. 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 list tool with full schema coverage, the description is mostly sufficient. The comparison with list_students clarifies output scope, but without an output schema, return-field details are somewhat underspecified. Still, the core usage is clear.
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% and all parameters have descriptions, so the baseline is 3. The description adds no extra parameter meaning; it merely lists role examples that are already in the schema enum, and omits 'designer' from the list.
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 users in a course' and allows filtering 'by role', with specific examples. It also explicitly differentiates itself from the sibling list_students, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs list_students: 'Simpler output' versus needing 'enrollment details like section, activity time, or state.' This gives the agent a clear decision rule.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a key side-effect: individual items retain their own published state. This is valuable nuance, though it doesn't mention idempotency, permissions, or error behavior.
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 short sentences: the first states action and effect, the second adds a critical caveat. There is zero filler or redundancy, and it is front-loaded with the verb and resource.
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 operation with no output schema, the description covers the essential purpose and a critical nuance about its scope. It doesn't describe the response format or error conditions, but those are not required here.
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 (course_id, module_id) are fully described in the input schema (100% coverage). The description adds no additional parameter-level detail, 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 uses a specific verb 'publish' with resource 'module' and immediately clarifies the effect ('makes it visible to students'). The note about publishing only the container distinguishes it from item-level publish operations and sibling tools like update_module.
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 use when you want to publish a module, and the note about container-only sets clear expectations about what the tool does not do. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the transparency burden. It states the output (counts of graded, ungraded, not submitted) and implies a read-only operation, but does not clarify edge cases like whether submissions with no grade are considered 'ungraded' or how 'not submitted' is determined, leaving some ambiguity.
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-loaded with the purpose, and includes the alternative. Every word contributes, with no fluff. Excellent 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?
No output schema exists, but the description explains the return content (counts of three categories). It omits the exact field names or data types of the output, and lacks context on how counts are derived, but for a simple summary tool with clear parameter scope, it is largely 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% for both parameters (course ID and assignment ID), so baseline is 3. The description adds no additional parameter details, relying on the schema. This is acceptable but not extra helpful.
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 provides a 'quick overview of submission status' with counts of graded, ungraded, and not submitted. It explicitly distinguishes itself from the sibling `list_submissions` for individual details, satisfying the verb+resource requirement.
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 gives an explicit alternative: 'For individual submission details, use list_submissions instead.' This tells the agent when to use this tool (overview counts) versus the sibling, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the limitation on updatable fields and references list_discussions for obtaining assignment_id, but it does not mention permissions, side effects, or return behavior. This is helpful but not comprehensive for a mutation tool without 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-loaded with the primary purpose, and includes an explicit alternative. Every sentence provides distinct value with no 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 update tool with five parameters and no output schema, the description covers the essential scope and exclusions clearly. It lacks notes on partial update behavior or return values, but given the tool's modest complexity, it 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?
Schema coverage is 60% with descriptions on course_id, discussion_id, and message. The description adds clarity by explicitly listing the updatable fields (title, message, published), which helps map intent to parameters. However, it does not add format or constraint details for the unannotated parameters (title, published), so it only partially compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a discussion topic's title, message, or published state, using a specific verb and resource. It also distinguishes itself from sibling tools by explicitly noting that it cannot update dates or points, which differentiates it from update_assignment and update_assignment_dates.
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 provides explicit when-to-use guidance by stating what cannot be updated and directing the user to alternative tools (update_assignment or update_assignment_dates) for those cases. It also implies the primary use case for updating discussion content fields, giving clear context for appropriate invocation.
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?
With no annotations, the description carries the burden and adds key behavioral context: only specified fields are changed, meaning unspecified fields remain unchanged. This is not apparent from the schema alone. However, it does not mention permissions, idempotency, or error behavior.
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 just two sentences, front-loaded with the verb+resource purpose and immediately followed by a useful usage note. Every word earns its place; no 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 update tool with no output schema and no annotations, the description provides the essential purpose and partial-update behavior. Required identifiers are clear from the schema. Gaps like field-level explanations and error behavior are minor since the tool is straightforward and the fields are mostly self-explanatory.
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 57%, and the description adds a general rule that all optional fields are changeable via partial update. However, it does not explain the semantics of title, position, or published, which are also undescribed in the schema. The partial-update note provides some value but not full compensation.
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 uses a specific verb 'Update' with the resource 'module item', making it clear this modifies an existing item within a module. This distinguishes it from sibling tools like add_module_item, delete_module_item, and update_module (which updates the module itself).
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 instruction 'Only include fields you want to change' provides clear partial-update usage guidance. While it does not explicitly name alternatives, the resource focus and required IDs imply this is for editing existing items rather than creating or deleting them.
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?
With no annotations provided, the description carries the full burden. It discloses the exact fields returned (id, title, start_date, end_date, is_closed) and the behavior for schools without grading periods (a single default period). It also explains how the IDs can be used downstream. It could mention error cases or ordering, but for a simple list operation, this is strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured: purpose, return fields, and usage guidance are clearly front-loaded. Every sentence adds value with no repetition 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 single-parameter list tool with no output schema, the description is remarkably complete. It explains the return format, an edge case (default period), and how the results are meant to be used in the broader grading context, leaving no significant gaps for the agent.
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?
Only one parameter exists, and the schema already describes it as 'Canvas course ID' with 100% coverage. The description adds minimal additional semantics beyond 'a course's term', 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 uses a specific verb ('List') and names the resource ('grading periods') with clear scoping to 'a course's term'. It differentiates from sibling tools like list_calendar_events and list_terms by focusing solely on grading periods and even explains their purpose in the grading workflow.
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 states when to use this tool: to obtain grading_period_id values for scoping grades/submissions to a single period, as opposed to using the cumulative lifetime grade. It also provides the important caveat about schools without grading periods. However, it does not explicitly discuss alternative tools or when not to use it, so it falls short of 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals two important traits: changes apply to all assignments using the rubric, and omitting criteria preserves existing criteria. This adds value beyond the schema, although it does not explicitly detail the destructive replacement behavior when criteria are passed (but this is implied and covered by the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the verb and resource. Every sentence contributes meaningful information: what the tool does, the global scope, and a key behavioral guarantee. No fluff or 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?
The tool is moderately complex with 5 parameters and no output schema, but the schema fully documents all parameters. The description covers the core operation and notable side effects, making the tool's behavior well-understood. It does not explain return values, but none are defined, so this is not a 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?
All 5 parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds minimal extra semantic value, only mentioning the behavior of title-only updates. It does not provide additional syntax or format details 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 clearly states the tool updates an existing rubric's title, criteria, or display settings. It uses a specific verb ('Update') and resource ('existing rubric'), and distinguishes it from sibling tools like create_rubric, delete_rubric, and associate_rubric.
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 for when to use the tool: updating an existing rubric. It does not explicitly name alternative tools or exclusions, but the scope is unambiguous. The behavior note about preserving criteria when only the title is changed serves as a partial guideline.
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?
With no annotations, the description carries the burden of behavioral disclosure. It explains a key non-obvious behavior: assignments with section overrides ignore the base date, and if only due_at is provided, all overrides receive the same time. This is valuable beyond the schema. It does not cover potential partial failures or return format, but the core edge case is well documented.
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, front-loaded with the main purpose, then diving into essential edge-case behavior. No word is wasted; the example object shorthand is compact and informative.
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 absence of an output schema and annotations, the description sufficiently covers the complex override logic and input structure. However, it omits any indication of the response format or error handling for invalid assignment IDs, which would be useful for a batch operation.
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?
Although schema coverage is 100%, the description adds crucial semantic meaning beyond field names, particularly how due_at and section_dates interact with overrides. It also illustrates the expected array object shape, which helps the agent construct valid input.
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 immediately states 'Update dates for multiple assignments at once', which clearly specifies the action ('update dates'), the resource ('multiple assignments'), and the batch scope. This distinguishes it from singular assignment date tools like update_assignment_dates and from generic batch_update_assignments that might handle other fields.
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 explicit guidance on override-aware behavior: if overrides exist, update those instead of the base date, and explains when to provide section_dates vs. relying on due_at. However, it does not explicitly mention alternatives or when to choose this tool over other batch tools, so it stops short of full when/when-not 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?
With no annotations, the description carries the full burden. It discloses the key side effects: deletes the assessment row, clears the grade, and explicitly states what it does NOT affect (the rubric itself, other students). It omits irreversibility, permissions, and error behavior, but the primary impact is well covered.
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. The first sentence states purpose and effects; the second provides retrieval instructions. Every word earns its place with no redundant content.
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?
Considering the tool's simplicity (3 params, no nested objects) and the detailed schema, the description is nearly complete. It covers the operation, the outcome, and the prerequisite lookup. It doesn't mention return values or errors, but for a straightforward delete with no output schema, that is a minor gap.
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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaningful guidance on how to obtain rubric_association_id and assessment_id ('by calling get_rubric with include=["assessments"]'), which goes beyond the schema and helps the agent select and invoke the tool correctly.
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 ('delete a single rubric assessment row') and clearly scopes the action: clearing only that student's rubric grade without removing the rubric or affecting other students. This fully distinguishes it from sibling tools like delete_rubric or update_rubric_assessment.
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 when to use this tool (to clear a single student's rubric grade) and provides explicit retrieval instructions for the required IDs via get_rubric with include=['assessments']. It does not name direct alternatives such as update_rubric_assessment or bulk deletion, so it falls slightly short of 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?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the lifetime-data limitation, lack of grading_period_id support, and the fallback, which are significant behavioral traits. It doesn't cover permissions or error conditions, but for a read-only analytics endpoint, the key caveats are addressed.
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 plus a note, every clause adds value: metrics, distinction from list_assignments, and lifetime-data caveat with fallback. No 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 one-parameter analytics tool with no output schema, the description clearly states return content and key limitations. It stops short of describing the exact response structure, but an agent would know what results to expect and when to use 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?
The schema already documents course_id fully ('Canvas course ID'), so the description doesn't need to repeat it. The description adds no extra parameter-specific semantics, but given 100% 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 opens with a specific verb+resource: 'Get aggregate statistical analytics per assignment' and enumerates exact metrics (min/max/median scores, submission counts). It explicitly distinguishes itself from siblings by noting 'not the assignments themselves' and pointing to list_assignments, which differentiates it clearly.
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: use this for aggregate statistics rather than assignment details, and explicitly warns that it returns lifetime data and does not support grading_period_id, directing users to list_submissions for semester-scoped data. This is an exemplary alternative-selection statement.
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?
With no annotations, the description carries the full burden. It discloses that the tool returns summary info and includes regular assignments, graded discussions, and New Quizzes as internally-all-the-same assignments, which is valuable nuance. However, it does not explicitly state read-only semantics or mention pagination, so it falls short of a perfect 5.
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, front-loaded with the primary action and resource. Each sentence provides distinct information: purpose, scope detail, and return summary plus alternative. There is no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a well-described schema, the description covers inclusion criteria, return summary, and points to get_assignment for more detail. It lacks explicit mention of default ordering or pagination, but these are either in the schema or not critical for a list operation, making it nearly 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?
The input schema has 100% description coverage for all 4 parameters, each with its own field description. The tool description adds no parameter-specific details beyond 'in a course' which simply maps to course_id. Since the schema already handles parameter meanings, 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 tool lists assignments in a course with a specific verb and resource. It also distinguishes from related sibling tools by noting it includes graded discussions and New Quizzes, and by directing users to get_assignment for full details.
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 says 'Use get_assignment for full details,' which is an alternative and a when-not-to-use directive. This provides clear guidance on when to prefer this tool versus get_assignment, satisfying the criterion for explicit 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?
With no annotations provided, the description carries the burden of disclosing behavior. It clarifies that this lists only students (not all roles) and includes specific enrollment data like section, activity, and last login. However, it does not mention pagination or any side effects, but for a read-only list tool this is a reasonable coverage level.
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: the first states the primary purpose and data scope, the second offers a clear alternative. No wasted words or redundant 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, the description is mostly complete. It explains the tool's purpose, what data is included, and when to use an alternative. It doesn't elaborate on filter semantics (already in schema) or return format (no output schema), but the description provides enough context for correct selection and 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?
Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description adds no parameter-specific detail beyond what the schema already documents, so no additional value is provided.
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 clearly identifies the resource as 'students enrolled in a course' with a defined scope ('enrollment-specific data'). It explicitly distinguishes itself from the sibling tool by contrasting with 'list_users_in_course'.
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?
Directly states the alternative use case: 'For a simpler user list with any role (teachers, TAs, etc.), use list_users_in_course instead.' This gives clear when-to-use and when-not-to-use guidance, citing the sibling 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?
With no annotations, the description carries the transparency burden. It discloses the critical behavioral guarantee: 'without changing the grade,' which prevents misuse. It also implies a non-destructive, additive operation ('Add a comment'). It does not mention side effects like student notifications or overwrite behavior, but these are less central to a comment tool and the description covers the most important behavioral boundary.
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 that are all useful: the main action, a contextual use case, and an explicit alternative. It is front-loaded with the core purpose and contains no filler. 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?
The tool is a simple mutation with 5 well-documented parameters. The description provides purpose, usage context, and an alternative, which is sufficient for an agent to select and invoke it correctly. No output schema exists, but the description adequately covers the main concerns; missing details like student notification are not essential for basic use. Slightly more detail on the group_comment behavior could be added, but it's already in the schema.
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 documents every parameter (course_id, assignment_id, user_id, comment, group_comment). The description adds no parameter-specific detail beyond what the schema provides. It only offers general context for the tool's purpose, which does not enhance parameter understanding. 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 opens with 'Add a comment to a student's submission without changing the grade', which clearly identifies the action (add comment), target (student's submission), and the key differentiator (no grade change). This distinguishes it from the sibling grade_submission tool, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Useful for leaving feedback during review or asking for revisions.' It also names an alternative for a related need: 'For comments + grade in one call, use grade_submission with the comment field instead.' This provides clear when-to-use and when-not-to-use 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?
With no annotations, the description carries the transparency burden. It discloses partial-update semantics ('Only include fields you want to change') and cross-resource compatibility, both non-obvious behaviors. However, it doesn't mention permissions, side effects on discussions/quizzes, or error conditions, preventing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose, then usage detail, then a pointed alternative. Every sentence adds value and there is no 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?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description covers key aspects: purpose, usage, scope, and alternative. Missing return/response details and permission requirements, but these are less critical for an update tool and the description is otherwise quite 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 coverage is 67%, so the schema handles most parameters but leaves name, position, published, and points_possible undescribed. The description adds general semantics about partial updates but doesn't detail these missing parameters. It partially compensates but doesn't fully bridge the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Update an existing assignment') and resource, and explicitly differentiates from sibling tools like update_assignment_dates by noting it also handles graded discussions and New Quizzes. This makes the tool's purpose unambiguous and distinct.
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 provides explicit usage guidance: 'Only include fields you want to change' tells the agent how to invoke it, and 'For date-only changes, prefer update_assignment_dates' offers a clear alternative. It also states that it works for other resource types, helping decide when to use it instead of update_discussion or update_new_quiz.
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?
With no annotations provided, the description must carry the full burden. It discloses critical behavior: 'Only include fields you want to change' indicates a partial update (PATCH) semantics, preserving omitted fields. It also explains the timing for scoring_data updates. It does not cover return values or permissions, but the core mutational behavior is well conveyed.
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-loaded with the primary purpose, and directly addresses usage. The second sentence packs important behavioral and workflow details without unnecessary words. Every sentence earns its place, making it highly concise 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?
The tool has 11 parameters, nested objects, no output schema, and no annotations. The description covers the primary use case and the most important behavioral nuance (partial update), and it leverages the schema's comprehensive parameter descriptions for the rest. It doesn't explain interactions between scoring_data and interaction_data or edge cases, but for a typical update flow it is reasonably complete.
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 input schema already describes all 11 parameters (100% coverage), so the baseline is 3. The description adds value by specifically highlighting the role of scoring_data in the create-then-update workflow and clarifying that only included fields are changed. This goes beyond the schema's generic descriptions, justifying a 4.
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 'Update an existing question (item) in a New Quiz', which combines a specific verb (update) with a specific resource (question in a New Quiz). This distinguishes it from sibling tools like create_quiz_item, delete_quiz_item, and get_quiz_item. It also adds the key detail that only included fields are changed, reinforcing the update purpose.
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 explicit usage context: 'Commonly used after create_quiz_item to set the correct answer IDs in scoring_data once the choice IDs are known.' This prescribes a workflow and indicates when to use this tool relative to creation. It lacks explicit exclusions or mention of alternatives, but the provided scenario is detailed and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds useful context about the tool's surgical scope ('without re-grading the whole submission', 'surgically edit one row'), but does not mention other behavioral aspects like whether the edit is reversible, required permissions, or how existing data is handled. The schema covers the replace behavior, but the description alone is 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?
Two sentences, front-loaded with purpose, then usage guideline. Every sentence earns its place with no fluff. Well-structured for an AI agent to quickly 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 tool with 5 parameters, no annotations, and no output schema, the description covers purpose, usage, and parameter lookup strategy. It doesn't explain the response after editing, but given the absence of an output schema, that's not required. It differentiates from siblings and provides enough context to use 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 baseline is 3. The description adds value by explaining how to obtain two key parameters (rubric_association_id and assessment_id) via a specific API call, and provides an example use case. This goes beyond the raw schema descriptions.
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 edits an existing rubric assessment, with a specific example ('correct one student's rubric grade') and distinguishes it from re-grading the whole submission. It also names the alternative grade_with_rubric, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool versus grade_with_rubric, and provides a concrete prerequisite: find rubric_association_id and assessment_id by calling get_rubric with include=['assessments']. This gives clear when/when-not 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?
With no annotations, the description carries the full burden. It discloses that the operation modifies settings 'without re-associating', which is a key behavioral trait. It also adds practical context about ID discovery and maps hide_points to the UI label 'Remove points from rubric'. It doesn't mention permissions or side effects, but it is transparent about the core behavior.
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, front-loaded with the primary purpose, and every sentence contributes meaningful information without redundancy or fluff.
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 6 parameters, no output schema, and no annotations, this description provides sufficient operational guidance: clear scope, specific settings, and a method to find the association ID. It doesn't explain return values, but the task is straightforward and the schema covers parameter details.
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 baseline is 3. The description adds value by clarifying that association_id is not the rubric ID or assignment ID, and by explaining the UI mapping for hide_points. These details go beyond the schema descriptions and help avoid misuse.
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 identifies the verb 'Update' and the specific resource 'display/grading settings of an existing rubric–assignment association', distinguishing it from re-associating. It also enumerates concrete settings (hide_points, hide_score_total, use_for_grading), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool ('Use this to toggle...') and tells how to find the required association_id via get_rubric. It implicitly differentiates from re-associating, but doesn't name sibling tools like associate_rubric or remove_rubric_from_assignment as alternatives, leaving a small gap.
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?
With no annotations, the description carries full burden. It discloses a key behavioral trait: returns per-criterion data but omits assessment row IDs, which is critical for follow-up operations. The read-only nature is implied by 'Get all' but not explicitly stated; still, the key limitation is covered.
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-loaded with the core purpose, and the follow-up note about row IDs is essential and efficiently phrased.
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 two-parameter tool with no output schema, the description explains the output content and a critical limitation. It also points to the alternative for getting row IDs, making it sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 descriptions for course_id and assignment_id. The description adds no additional parameter-specific meaning, so 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 fetches all rubric assessments for an assignment, showing per-criterion scores per student. It also differentiates from get_rubric by noting it does not return row IDs, which helps select the correct tool.
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 instructs that if assessment row IDs are needed (for update/delete), one should call get_rubric with include=['assessments'] instead. This gives clear when-to-use and alternative 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by revealing the implementation approach ('by filtering assignments') and the nature of the return value ('Returns a summary of each'). This goes beyond a minimal description, though it could further disclose potential performance implications or output field specifics.
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, front-loaded with the main purpose and output, followed by important alternative references. Every sentence earns its place with no 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?
This is a simple one-parameter list tool with no output schema or annotations. The description explains what the tool does, how it works, what it returns, and how to use related tools, making it fully sufficient for selecting and invoking 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% (the single parameter course_id is described as 'Canvas course ID'), so the schema already fully documents the parameter. The description adds no additional parameter-specific meaning, warranting the baseline score 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 ('List') and clearly identifies the resource ('New Quizzes (Quizzes.Next) in a course'). It also distinguishes itself from sibling tools by pointing to get_new_quiz for full details and quiz item tools for question management.
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 this tool (to list all New Quizzes) and provides direct alternatives for related needs (full details via get_new_quiz, question management via list_quiz_items/create_quiz_item). This is clear guidance on selection.
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?
With no annotations, the description carries the full burden. It discloses the operation's scope (multiple assignments), the unsupported field type (date fields), and the uniform application semantics. However, it does not mention error handling, partial failure behavior, or permissions, preventing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, followed by the critical caveat about date fields and the uniform application model. Every sentence earns its place with no 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?
Given the tool's complexity (nested updates object, batch operation) and lack of annotations or output schema, the description covers the essential context: what it updates, its limitation, and how it applies updates. It does not specify return values or error semantics, but the core behavioral contract is clearly communicated.
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 schema descriptions cover all three parameters, providing a baseline of 3. The description adds important context beyond the schema: that date fields are not supported within updates and that the same update is applied to every assignment ID, enhancing understanding of the updates and assignment_ids parameters.
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 begins with 'Update fields across multiple assignments at once,' clearly stating the action and resource. It distinguishes itself from singular update tools and explicitly excludes date fields, pointing to batch_update_dates as a sibling for that use case.
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?
It explicitly names batch_update_dates as the alternative for date changes and clarifies that the operation applies the same update to each assignment ID, signaling when to use this tool versus update_assignment or batch_update_dates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It discloses the copy behavior, field inheritance for display toggles, default target course, and the important caveat that outcome-linked criteria may be stripped if the outcome is unavailable in the target course. This goes well beyond a generic 'duplicates a rubric' statement.
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, front-loaded with the core purpose, and every sentence adds meaningful detail. There is no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity (8 params, no output schema) and the description covers the central behaviors, options, and a notable edge case. It does not describe the return value or error behavior, but given the schema richness and lack of output schema, the description is sufficiently complete for an agent to invoke 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 baseline is 3. The description adds value by explaining that display toggles are inherited from the source's primary association unless overridden, which enriches the meaning of the three hide_* boolean parameters. It also clarifies the default behavior of target_course_id and new_title, though the schema already documents these.
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 opens with a specific verb and resource: 'Duplicate an existing rubric.' It clearly enumerates what is copied (title, criteria, ratings, long descriptions, outcome links, free_form_criterion_comments) and distinguishes itself from sibling rubric tools like create_rubric or update_rubric by focusing on duplication semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the default same-course behavior and how to copy cross-course via target_course_id, and mentions optional renaming/assignment association. It does not explicitly name alternative tools to use instead, but the duplication context is unambiguous enough to guide tool selection.
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?
No annotations are provided, so the description carries the burden. It clearly states the tool's informational nature, scope, and that it includes mounting instructions. Since it's a read-only description tool, this is adequate, though it doesn't explicitly mention output format or that it's non-destructive.
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 action and scope, followed by usage guidance. Every word earns its place; no 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?
Given the tool's simplicity (0 params, no output schema), the description covers purpose, content, and when to use. It fully equips the agent to understand what this meta-tool provides, without needing additional details about return structures.
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 baseline is 4. There is no input schema to explain, and the description correctly doesn't attempt to document nonexistent parameters.
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 ('Describes') and identifies the exact resource ('three Canvas-Agent MCPs (core/admin/extras)') and content ('what tools live in each, and how to mount the other two'). This clearly distinguishes it from the sibling tools, which are all individual Canvas operations.
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?
It provides explicit trigger conditions: 'Call this when a user asks about Canvas-Agent's capabilities, or when you need a Canvas tool that doesn't appear to be registered — it's likely in admin or extras.' This tells the agent exactly when to use it and even hints at the alternative (searching registered 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?
No annotations are provided, so the description carries the transparency burden. It discloses that the tool returns all criteria and rating scales, and that including 'assessments' retrieves every rubric_assessment row with IDs. This implies a read-only operation and communicates the data scope, though it does not mention potential volume or pagination, preventing a perfect score.
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-loaded with the primary purpose. Every sentence is informative and necessary: the first explains the main function, and the second provides critical downstream usage context. No wasted words.
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?
Despite having no output schema, the description adequately conveys what the response contains (criteria, rating scales, optional assessment rows with IDs) and clearly ties to sibling tools (grade_with_rubric, update_rubric_assessment, delete_rubric_assessment). The tool's complexity is well covered given the rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters (100% coverage), so the baseline is 3. The description adds value beyond the schema by explaining the practical importance of the 'include' parameter (specifically 'assessments') and how returned IDs are used by other tools, enhancing understanding of the parameters' purpose.
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's function with a specific verb and resource: 'Get full details of a rubric, including all criteria and their rating scales.' It distinguishes itself from sibling tools like 'list_rubrics' (which only lists) and 'get_rubric_assessments' (which focuses only on assessments) by emphasizing the comprehensive nature of the response.
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 explains when to use this tool relative to alternatives: the returned criterion IDs are needed by grade_with_rubric, and passing include=['assessments'] provides the IDs needed by update_rubric_assessment and delete_rubric_assessment. This gives clear guidance on how this tool fits into workflows with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly discloses that the endpoint returns LIFETIME data, does NOT support grading_period_id, and includes all grading periods. This reveals important behavioral traits beyond the basic function.
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 core purpose, then caveats. No redundancy or filler; every sentence 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?
Despite no output schema and no annotations, the description covers purpose, usage alternative, and a critical caveat (lifetime data). For a simple 2-parameter read tool, this is complete and well-contextualized.
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 already described as 'Canvas course ID' and 'Canvas user ID of the student.' The description adds no additional parameter details, so 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 gets per-assignment scores, submission status, and timestamps for a specific student. It uses a specific verb ('Get') and resource, and distinguishes itself from siblings by noting it is analytics data and pointing to list_submissions for actual submission details.
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 states when to use this vs. list_submissions: 'for actual submission details, use list_submissions.' Also warns about lifetime data and lack of grading_period_id, guiding users away from this tool when grading-period filtering is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a critical behavioral trait: 'this endpoint returns LIFETIME data and does NOT support grading_period_id — the tardiness counts include all assignments since the course began, not just the current semester.' This goes beyond a basic description and warns about a common misuse.
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?
Three sentences, each earning its place: first states purpose, second gives sibling alternative, third explains the lifetime-data caveat and alternative approach. Front-loaded and concise with no 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?
Despite no output schema, the description lists the returned data (page views, participations, tardiness breakdown) and important limitations (lifetime, no grading_period_id, per-semester workaround). This is complete for a simple analytics tool and covers the essential context an agent needs.
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 'course_id' and 'sort_column' having descriptions (including enum values). The description does not add much about these parameters beyond the schema, but it clarifies that grading_period_id is not accepted, which is useful context. 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's function: 'Get per-student engagement analytics for a course: page views, participations, and tardiness breakdown (missing/late/on_time counts).' It uses a specific verb and resource, and the inclusion of 'For enrollment/roster data, use list_students instead' distinguishes it from a sibling tool.
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 names an alternative ('use list_students instead') and provides a when-to-use-other guidance for per-semester counts ('iterate course submissions with a grading_period_id filter'). It also explains the lifetime-data limitation, giving clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses critical behavioral details beyond the schema: the two-step creation process for choice-based questions ('Create with placeholder scoring_data first... Then use update_quiz_item to set the correct answer ID'), the fact that the API generates choice IDs on creation, and the option to reference by position. This is exactly the kind of non-obvious behavior an agent needs.
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?
Despite its length, every sentence earns its place. The description is front-loaded with the purpose and then organized by interaction type in a numbered, scannable format. The TIP at the end consolidates key workflow guidance without redundancy. Appropriate size given the tool's inherent complexity (13 interaction types).
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?
The tool has 10 parameters, nested objects, and 13 distinct interaction modes. The description comprehensively covers all modes, gives data formats, and explains the return behavior (API returns generated choice IDs). It also includes a workflow tip for handling the most complex case. No output schema exists, but the description adequately conveys the essential return information needed to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description goes far beyond the schema's terse property descriptions. It provides per-interaction-type structures for both interaction_data and scoring_data, with concrete JSON examples, naming fields like 'item_body', 'position', 'match_id', and 'category_id'. This dramatically enriches parameter understanding and reduces ambiguity for constructing valid inputs.
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 opens with 'Create a question (item) in a New Quiz. This is the primary tool for adding questions.' This is a specific verb ('Create') + resource ('question/item in a New Quiz') and clearly distinguishes the tool from siblings like get_quiz_item, update_quiz_item, and delete_quiz_item.
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 explicitly labels itself as the 'primary tool for adding questions' and includes a detailed TIP that directs users to create first, then use update_quiz_item for scoring_data corrections. This provides clear workflow context. However, it doesn't explicitly list situations where another tool should be used instead, though the context strongly implies it.
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-Agent MCP server](https://glama.ai/mcp/servers/hughsibbele/Canvas-Agent/badges/card.svg)](https://glama.ai/mcp/servers/hughsibbele/Canvas-Agent)

Score Badge

Copy to your README.md:

[![Canvas-Agent MCP server](https://glama.ai/mcp/servers/hughsibbele/Canvas-Agent/badges/score.svg)](https://glama.ai/mcp/servers/hughsibbele/Canvas-Agent)

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/hughsibbele/Canvas-Agent'

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