canvas-mcp-lite

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Despite the large number of tools, most target distinct resources and actions (e.g., list_courses vs. list_assignments). However, a few overlaps exist: delete_discussion_topic also handles announcements, and get_course_structure overlaps with list_modules and list_pages in purpose. These are minor and descriptions clarify boundaries.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (list_, get_, create_, update_, delete_, etc.). Even less common verbs like post_grades, hide_grades, and send_message adhere to the same style. This makes the set predictable and easy to navigate.
Tool Count4/5
64 tools is high, but the server covers a wide Canvas LMS domain including courses, assignments, grades, modules, pages, discussions, files, quizzes, announcements, messages, peer reviews, and analytics. Each tool has a clear purpose, so the count feels justified rather than bloated, though it may be intense for agents to discover.
Completeness4/5
The surface is comprehensive with full CRUD for many resources (assignments, pages, modules, announcements, rubrics) and extensive grading/peer review capabilities. Minor gaps exist (e.g., no course editing or user creation), but core workflows like grading and course content management are fully covered.
Average 3.4/5 across 64 of 64 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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. The description merely restates the action without mentioning side effects, permissions, reversibility, or what happens after replying. It does not disclose that this is a write operation or any other behavioral traits beyond the obvious action implied by 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It adds no context beyond the action itself and does not front-load any critical information. The structure is not helpful for an agent seeking to understand when and how to use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, no annotations, and an output schema that is not described in the definition, the description is wholly inadequate. It does not mention any prerequisites (e.g., existing topic/entry), the expected response shape, or any nuances that would help an agent invoke it correctly. The tool is yet another discussion-related operation among many siblings, and this description does nothing to place it in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for the lack of parameter documentation. The description does not explain any of the four parameters (course_identifier, topic_id, entry_id, message) or provide any additional meaning beyond their names. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Reply to a specific entry in a discussion topic.' This is a specific verb and resource, and it distinguishes from siblings like 'post_discussion_entry' (creating a new entry) and 'list_discussion_entries' (listing entries). It is clear enough for an agent to understand the primary function.
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 like post_discussion_entry or list_discussion_entries. It does not mention any context, prerequisites, or exclusions. An agent would have to rely on the tool name and sibling names to infer usage.
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. The only behavioral trait mentioned is that the module 'starts unpublished', which is useful but insufficient. It does not disclose permissions required, whether the operation is reversible, what happens to existing modules on position conflict, or any side effects. For a create operation with no annotation support, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action, but it is under-specified. For a tool with three parameters and no other documentation, this is not appropriately sized; it lacks necessary detail. It is concise to the point of being unhelpful, similar to a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (two required), no annotations, and an output schema, the description is grossly incomplete. It does not explain what the parameters mean, what the expected output is, any constraints, or how it relates to sibling tools like update_module or list_modules. An agent cannot confidently call this tool correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention name, position, or course_identifier at all, nor does it clarify their meaning or format. The description adds no semantic value beyond the raw schema, which is undocumented. This is a complete failure to help an agent understand what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'create' and the resource 'module', which is clear and unambiguous. It also adds the behavioral detail that it starts unpublished, which helps distinguish it from a generic create operation. However, it does not explicitly differentiate from sibling create tools like create_assignment or create_page, though the resource is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_modules, update_module, or add_module_item. It does not state whether it should be used only for creating new modules or any context for prerequisites or typical scenarios. There is no mention of alternatives or 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Remove,' implying deletion but not clarifying irreversibility, permission requirements, cascading effects, or what the operation returns. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action. It is appropriately short for a straightforward delete operation, though it could include more detail without sacrificing conciseness. Efficiency is high.
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?
This is a mutation tool with four required parameters and no annotations. The description lacks information about return values, side effects, prerequisites, or error handling. Given the absence of schema descriptions and the need to guide an agent, the definition is incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters (course_identifier, assignment_id, reviewee_user_id, reviewer_user_id). While parameter names are somewhat self-explanatory, the description adds no additional meaning or context to help an agent understand their roles or constraints.
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 ('Remove') and resource ('previously assigned peer review'), which clearly conveys the action and differentiates it from siblings like assign_peer_review and list_peer_reviews. It is not a tautology and gives a precise object of the action.
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 guidance on when to use this tool versus alternatives such as assign_peer_review or list_peer_reviews. No conditions, prerequisites, or exclusion criteria are provided, leaving the agent to infer usage intent without explicit support.
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 'List rubrics available in a course,' which implies a read-only operation but doesn't explicitly state that, nor does it mention any error conditions, pagination, or ordering. It lacks sufficient transparency for a tool with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately front-loaded with the verb and resource. For a simple list tool, this level of conciseness is acceptable, though it could include a bit more detail without becoming verbose.
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 only one parameter and is a straightforward list operation, but the description omits details about the return value, potential errors, pagination, or what 'available' means (e.g., published rubrics). Given that an output schema exists but is not described, the description still leaves uncertainty about expected behavior.
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 does not explicitly describe the 'course_identifier' parameter; it only says 'in a course,' which hints at the parameter's role but doesn't explain its format or required values. With 0% schema description coverage, the description should compensate, but it provides only a weak hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and resource (rubrics) with a scope ('in a course'). This distinguishes it from sibling tools like get_rubric (single rubric) and create_rubric. However, it is minimal and doesn't specify nuances like whether it lists all rubrics or only published ones.
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 mention of when to use this tool instead of alternatives, no exclusions, and no context about typical use cases. The description only states what it does, leaving the agent to infer when to call it.
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 available, so the description must disclose behavior. It only states the basic function, without mentioning pagination, ordering, whether sections include only published/active ones, error handling, or authorization requirements. It adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes a useful detail (student counts). It is appropriately sized for a simple list operation, 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?
For a simple list tool with a single parameter and an output schema, the description is minimal but arguably sufficient to understand the core function. However, it lacks context about behavior like pagination, visibility filtering, or relationship to other course entities, and doesn't mention any limitations. Given the presence of many sibling tools, a slightly richer description would aid correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the course_identifier parameter beyond implying it identifies a course. Schema coverage is 0%, so the description was expected to compensate, but it only indirectly references the parameter ('in a course'). No guidance on format, requiredness (though schema says required), or how to obtain the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('sections') scoped to a course, and the qualifier 'with student counts' adds specificity. It can be differentiated from sibling tools like list_courses (lists courses) and list_users (lists users), though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_courses or get_course_details. There is no mention of use cases, prerequisites, or exclusions. The tool's purpose is implied but not contextualized.
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 mentions 'grade/submission status' but does not clarify whether it returns all submissions or only graded ones, nor does it mention pagination, permissions, or any side effects. For a read-like list operation, the lack of explicit safety statements is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is front-loaded and easy to parse, though it omits important contextual details. This is concise but not to the point of under-specification; it's acceptable for the limited purpose it states.
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?
Given the tool's specificity and the existence of sibling tools, the description should explain when to use it and what distinguishes it from related list tools. It does not. The output schema likely covers return values, so that is not an issue, but the lack of usage guidance and behavioral caveats makes it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It does not mention course_identifier or assignment_id at all. The names are somewhat self-explanatory, but the description adds no semantic detail about their expected format or relationship, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('submissions'), and a scope ('for an assignment'), and adds that it includes grade/submission status. This clearly differentiates it from ungraded/missing variants, though it doesn't explicitly name those siblings. It's clear and concise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like list_ungraded_submissions or list_missing_submissions. There is no mention of conditions, prerequisites, or exclusions. The agent is left to infer when this general list is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 lists actions without revealing side effects, permission requirements, reversibility, or behavior for omitted parameters. It does not even explicitly state that it mutates an existing module, though 'rename/publish/reposition' implies it. This is a major gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and the primary actions are listed up front. However, its brevity border on under-specification; while concise, it sacrifices necessary detail for other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, 2 required, and zero schema descriptions, this description is inadequate. It does not explain partial update behavior, which fields can be combined, or any constraints (e.g., whether position is relative). An agent would need to guess or consult the schema, but the schema has no descriptions either. The output schema exists but is not referenced or explained. This is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'rename, publish/unpublish, or reposition,' which loosely maps to name, published, and position, but it does not clarify which parameters are required, optional, or how they interplay. The parameter names are somewhat self-explanatory, but the description adds minimal value beyond the schema's bare property names.
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 (rename, publish/unpublish, reposition) applied to a specific resource (module). These actions map directly to the parameters (name, published, position) and clearly distinguish the tool from siblings like create_module or add_module_item. No ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or that it only modifies existing modules (as opposed to creating them). An agent cannot infer usage context from the text alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It states this is a 'get' operation, implying read-only, but does not state so explicitly. It does not mention any side effects, permissions required, rate limits, or error conditions. The lack of any behavioral context beyond the action verb leaves agents uncertain.
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 redundant words. It is front-loaded with the action ('Get full details') and the object ('one assignment'). Perfectly concise and to the point.
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?
Given the existence of many sibling tools and the minimal description, the definition is incomplete for an agent to use it correctly. While the output schema exists (which explains return value structure), the description does not clarify the input parameters, usage context, or how it differs from similar tools. The tool is simple, but the description leaves too much unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. Both parameters (course_identifier and assignment_id) are named but not explained. The description does not clarify their formats, required types, or how they relate (e.g., whether assignment_id is scoped by course_identifier). No additional meaning is provided beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full details for a single assignment, including the description. It distinguishes itself from list_assignments (which lists all) and get_assignment_analytics (which focuses on analytics). However, it does not enumerate what 'full details' encompasses beyond description, leaving some ambiguity about the exact scope.
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 its siblings. There is no mention of alternatives like list_assignments for viewing summaries or get_assignment_analytics for metrics. The intended use case (fetching a specific assignment's details) is implied by the name and description, but not explicit.
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 burden for behavioral disclosure. It only states the returned fields (scores, completion status) and implies a read-only operation, but does not disclose pagination, filtering behavior, whether only graded submissions are returned, or any side effects. Significant gaps remain.
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 and resource. No filler or redundancy; it is appropriately front-loaded and minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists (though not shown) so return values need not be explained. However, the description lacks usage guidance, does not clarify scoping (e.g., all submissions or only those with scores), and does not address potential ambiguity with sibling list tools. It is minimally adequate but leaves important context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no explanation of what course_identifier or quiz_id represent, no format expectations, or any guidance beyond their names. While the parameter names are self-explanatory, the description adds zero semantic value and fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'student submissions for a classic quiz', and specifies the included data (scores and completion status). It distinguishes itself from generic list_submissions by the qualifier 'classic quiz', though it doesn't explicitly name the sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs siblings like list_submissions, list_ungraded_submissions, or list_missing_submissions. The description does not mention any conditions, exclusions, or preferred contexts for selection.
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 clarifies that the topic is non-announcement, but does not mention side effects, the meaning of the 'published' default, required permissions, or potential impacts. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and is front-loaded with the primary action. However, it is under-specified: there is no wasted text, but the brevity comes at the cost of missing operational details, so it is not appropriately sized for the tool's complexity.
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?
Given four parameters, zero schema descriptions, and no annotations, the description is far from complete. Although an output schema exists, the description does not clarify return behavior, parameter semantics, or usage prerequisites, leaving the agent underprepared.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the parameters (title, message, published, course_identifier). The agent is left to infer meaning solely from parameter names, which is insufficient for correct invocation.
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: 'Create a new (non-announcement) discussion topic.' It clearly distinguishes from the sibling create_announcement by explicitly excluding announcements, making it easy for an agent to select this over related creation 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 phrase 'non-announcement' implicitly signals that this tool is for regular discussion topics, not announcements. However, it does not state when to use it over other discussion-related tools (e.g., post_discussion_entry) or provide any conditional guidance. The usage context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must carry the full burden of behavioral disclosure. It clearly states the irreversible, permanent nature of the deletion, which is a critical behavioral trait. However, it does not disclose any other side effects (e.g., cascading deletes, permission requirements) or behavior on missing IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. It front-loads the core action and then reinforces irreversibility. Could be merged into one sentence, but it is appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the essential behavior (permanent deletion). It does not mention required parameters (though present in schema) or any side effects like related announcements or discussion threads. Given the absence of annotations and the simplicity of the operation, a 3 reflects the minimal but sufficient coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention course_identifier or announcement_id at all, offering no guidance on formats, types, or how they relate. A clear failure to add value beyond the raw 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 ('delete') and resource ('an announcement'), with the explicit qualifier 'Permanently' and 'cannot be undone.' This clearly differentiates it from update or create operations, and the singular 'an announcement' distinguishes it from bulk_delete_announcements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like bulk_delete_announcements or update_announcement. The description offers no contextual cues for typical use cases or 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?
Since no annotations are present, the description carries the full burden of behavioral disclosure. It only says what the tool gets, not how it behaves: no mention of pagination, size limits, permissions, or whether the result is nested vs flat. This is a significant gap for a read operation that could return a large hierarchy.
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, directly stating the action and scope. It is front-loaded and efficient, avoiding any redundant information. This meets the standard of every word earning 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?
Although an output schema is present, the description lacks critical context: it does not clarify the difference between this tree and list_modules, nor does it describe the structure returned. The ambiguity could lead to incorrect tool selection. For a tool with a single parameter but a potentially large output, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the course_identifier parameter at all, and schema coverage is 0%. The schema allows string or integer but does not clarify format (e.g., Canvas ID vs SIS ID). With a single required parameter and no description, the agent must guess its meaning, so the score is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and a precise resource ('full module/item tree for a course'). This distinguishes it from siblings like list_modules (which likely returns only modules) and get_course_details (course info). The 'in one call' additionally implies a comprehensive alternative to stepwise fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus list_modules or other course-structure tools. The phrase 'in one call' suggests efficiency but does not name the alternative or the exact conditions that would favor it. An agent has to infer the trade-off without direct instruction.
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, but it only states the action without revealing what is returned (e.g., metadata, pagination), whether permissions are needed, or any other side effects. It adds little beyond the tool's 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 a single, concise sentence with no wasted words. It is optimally short for a simple tool and easy to parse.
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 low-complexity tool with one parameter and an existing output schema, the description is minimally sufficient. However, it omits any mention of pagination, filtering, or ordering that might be relevant for a list operation, and it gives no context about permissions or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It mentions 'a course' but does not explain the course_identifier parameter beyond that, nor does it clarify the acceptable types (string or integer). The parameter name is self-explanatory, but the description provides no additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('files uploaded to a course'), making the tool's purpose clear. It distinguishes from siblings like read_course_file or upload_course_file, though it doesn't explicitly reference them. The wording is unambiguous and adequate for a simple list operation.
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 guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions. An agent must infer from the tool name and siblings that this is for listing files in a course.
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 fully disclose behavior. It implies a mutation (changing 'published') but doesn't state side effects, reversibility, permissions, or whether only the published field changes. There's no mention of errors or return behavior. The tool name suggests broader 'settings' but the description narrows it, which could confuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It is front-loaded with the core action and is easy to parse. There is no unnecessary filler.
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 an output schema, the description omits any guidance on how to identify a page (e.g., how to obtain page_url), what course_identifier expects, or whether published must be explicitly true/false. It doesn't clarify that it only changes publication status, not other settings. For a simple toggle, this is minimal, but an agent might need more context to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter details. It doesn't explain what course_identifier, page_url, or published mean, how to format them, or how they relate to the action. The description must compensate for missing schema descriptions but does not.
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 is specific: 'Publish or unpublish a page.' It names the verb and resource clearly. It distinguishes from siblings like edit_page_content (which alters content) and create_page (which creates a page) by focusing on the published status toggle. The action 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., page must exist), nor does it explain that this tool is specifically for toggling publication status and not for other settings. An agent has to infer usage from the name and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it gets details and message body, but does not mention potential limitations, required permissions, or any side effects. For a read operation, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, front-loading the action and resource. It is appropriately concise for a simple tool, though it could include a hint about parameters without bloat.
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?
While the output schema covers return values, the description fails to explain the required parameters at all, and with no annotations, it lacks guidance on authorization or edge cases. For a two-parameter tool, this is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. It doesn't explain what 'course_identifier' or 'topic_id' are, their format, or how they relate to the tool's purpose, forcing the agent to infer from sibling patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a specific resource ('full details and message body for one discussion topic'), and scopes it to a single topic, which distinguishes it from list_discussion_topics (list) and list_discussion_entries (entries). This is a precise and unambiguous 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 usage when you need details for a single topic, but it does not explicitly contrast it with sibling tools like list_discussion_topics or list_discussion_entries, nor does it mention any exclusions. The context suggests the right tool through the word 'one', but it lacks direct 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, the description must disclose behavior. It mentions that the assignment 'Defaults to unpublished,' which is a useful behavioral detail not obvious from the schema. It also explains the ISO-8601 format for due_at and comma-separated submission_types, adding context beyond the schema. However, it omits other behavioral aspects like permissions required, whether creation triggers notifications, or what happens to related resources.
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, with two sentences that deliver the core action and key format hints upfront. It avoids unnecessary fluff and each sentence earns its place. The examples for due_at and submission_types are directly useful and clear.
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?
An output schema exists, so return values are covered. However, the description does not clarify the full parameter set for an agent that has no prior context. It covers the non-required parameters due_at and submission_types but omits meaningful guidance on name, description, and points_possible. The presence of defaults in the schema partially mitigates this, but the description still leaves an agent to infer several parameter semantics. Overall adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains two parameters (due_at and submission_types) with format examples, but ignores the other five (name, description, points_possible, published, course_identifier). The required parameters course_identifier and name are not described at all; while their meaning is inferable from the tool name, the description fails to explicitly connect them. The partial coverage is insufficient for a 0% baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create an assignment' with a specific resource. It is not a tautology and distinguishes the tool's purpose from read-only tools, though it does not explicitly differentiate from other create tools like create_announcement or create_discussion_topic. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides format details for due_at and submission_types, but it gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or mention sibling tools like update_assignment, so an agent might not know that this tool is solely for creating new assignments rather than updating existing ones. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It discloses the default published state (draft unless published=True), which is a useful behavioral detail. However, it does not mention permissions, potential failures, or that it creates a new resource (though that is implied by 'Create').
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 that gets to the point immediately. It front-loads the core purpose and includes the key default behavior without any 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?
Given the schema defines required parameters and the output schema exists, the description is minimal but sufficient for a simple create action. However, it does not mention that the page is created within a course or any prerequisites. It is adequate but leaves some context to the agent's inference.
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 schema has 0% description coverage and the description adds minimal parameter semantics. It only clarifies the default for 'published' (as draft), but does not explain 'course_identifier', 'title', or 'body'. The schema itself provides defaults but no meaning, so the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('wiki page'), which distinguishes it from read or update tools like get_page_content or edit_page_content. It does not explicitly compare with sibling creation tools, but the resource type 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 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 instead of alternatives like edit_page_content or update_page_settings. An agent must infer from the name that this creates a new page rather than modifying an existing one. No exclusions or conditions 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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It does mention the output fields, which gives some indication of what to expect, and the verb 'Get' implies a read operation. However, it does not explicitly state that the operation has no side effects, whether any permissions are required, or how errors or missing data are handled. For a simple read tool, this is acceptable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the action and subject. There is no extraneous wording, making it easy to parse quickly. It could be slightly more informative without losing conciseness, but as is, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-one tool with one parameter, the description covers the core purpose and output fields. However, it omits usage guidance, and the output schema (though present) is not captured in the description. Given the many similar 'get' siblings, more context (e.g., what distinguishes this from get_syllabus) would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for course_identifier, and the description does not clarify what an identifier looks like (e.g., a numeric ID or a string code). With 0% schema coverage, the description should compensate, but it offers zero additional meaning about the 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?
Description clearly states the verb 'Get', the resource 'details for one course', and enumerates specific fields (code, name, dates, time zone, role). This makes the purpose unambiguous and distinct from siblings like list_courses or get_syllabus.
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 about when to use this tool versus alternatives. With many sibling tools (e.g., list_courses, get_course_structure, get_syllabus), an agent is left to infer selection criteria purely from the name and purpose. There is no mention of exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'get', implying a read operation, but does not state safety (read-only), authentication requirements, potential large payloads, pagination, or error behavior. There is no mention of what the response contains beyond 'full body' or whether it's HTML, plain text, etc. The description is too minimal to be 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?
The description is a single, concise sentence with no fluff. It front-loads the core action and resource, and the selector is mentioned succinctly. Every word earns its place, and it is appropriately short for a simple getter.
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 an output schema (which may document return values), but the description does not mention it or any error conditions, authentication, or prerequisites. The need for a course_identifier is completely absent from the description, and the notion of a 'URL slug' might be ambiguous (full URL vs path segment). Given the large sibling set, the description does not help the agent choose correctly or prepare the call, so it is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'page_url' is the URL slug, adding some meaning, but gives no explanation of 'course_identifier' (its role, format, or how to obtain it). The description fails to specify that a course context is required and offers no guidance on constructing a valid request. This leaves significant ambiguity for the agent.
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 (get), a specific resource (full body of a wiki page), and the identifying mechanism (URL slug). This distinguishes it from list_pages, which lists page metadata, and from get_syllabus/get_front_page, which target fixed pages. An agent can tell exactly what this tool does and when it is relevant.
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. There is no mention of when to prefer it over list_pages (e.g., when full content is needed) or any exclusions, requirements, or context such as needing to first call list_pages to obtain the slug. The description merely states functionality without usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'list' implies a read-only operation, but the description does not mention whether the operation is safe, whether results are paginated, what happens if the course does not exist, or any rate limits. It provides the basic behavior but omits important edge-case details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action ('List wiki pages in a course') and immediately specifies the return fields. It is concise with no wasted words, making it easy to scan and understand.
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 has a single parameter and an output schema (exists, though not shown), so the description does not need to detail return structure. However, it omits any mention of pagination, sorting, or error handling, and does not clarify whether the operation is read-only (important given no annotations). For a simple list operation, this is adequate but not fully complete.
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 schema defines a single parameter, course_identifier, with type anyOf string/integer, but provides no description. The tool description does not mention this parameter at all, so it adds no meaning beyond the schema's type constraint. Since schema description coverage is 0%, the description should compensate by explaining what the identifier represents or how to find it, which it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'list', the resource 'wiki pages', and the scope 'in a course', and specifies the return fields (publish status, last-updated time). It is clear and specific enough to distinguish from list_courses, get_page_content, and create_page, though it does not explicitly name any sibling to set it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid course_identifier), nor does it mention when not to use it (e.g., when a single page's content is needed). The usage context is merely implied by the tool's name and purpose.
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 itself. While it lists the modifications it can make, it does not mention side effects, permission requirements, reversibility, or what happens to other attributes when only some fields are changed. 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?
The description is a single concise sentence that front-loads the resource and all supported actions. There is no unnecessary verbosity or repetition.
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?
Given the tool's complexity (7 parameters, four distinct operations) and the absence of annotations, the description is incomplete. It does not explain how parameters map to operations, what the output schema contains, or any preconditions. An agent would need to infer most usage details from parameter names and schema types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the description must explain the parameters, but it mentions none of them. It does not map actions like 'reposition' to the 'position' parameter or 're-indent' to 'indent', leaving the agent to infer from parameter names alone. This provides almost no value over the raw 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 specifies the resource (a module item) and the four distinct operations it supports (rename, publish/unpublish, reposition, re-indent). This is specific enough to differentiate from sibling tools like add_module_item (creation) and delete_module (deletion) without needing to inspect the schema.
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 it is for modifying an existing module item, but it does not explicitly mention when to choose this over alternatives (e.g., update_module for module-level changes) or any conditions for use (e.g., item must already exist). It lacks explicit when-to-use/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.
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 the action without disclosing read-only behavior, required permissions, pagination, or any side effects. It adds no behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is minimally sufficient but lacks usage guidance and behavioral details. For an agent to correctly select and invoke it among many siblings, more context is needed.
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 input schema lists only conversation_id with no description, and the description does not clarify the format or meaning of the ID. Since schema coverage is 0%, the description should compensate, but it doesn't provide any additional parameter information.
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 'Get the full message thread for one conversation' uses a specific verb and resource, clearly indicating it retrieves the complete thread for a single conversation. It distinguishes from sibling tools like list_conversations, which likely lists conversations at a high level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_conversations or send_message. There is no mention of prerequisites, use cases, or when to choose this over other conversation-related 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, the description carries responsibility for behavioral disclosure. It adds a constraint ('classic quiz') and a hint of return contents, but does not explicitly state read-only nature, permission needs, or potential error conditions. 'Get' implies read, but more explicit disclosure would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without extra fluff. It front-loads the purpose and key output fields. However, it omits any usage or parameter context, so while concise, it is not maximally informative for the space used.
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?
Given the tool has an output schema and only two self-explanatory parameters, the description is incomplete for a read operation with zero annotations. It lacks usage guidance, parameter clarification, and any note about the 'classic' qualification. An agent may fail to select or invoke it correctly without more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention course_identifier or quiz_id at all, nor how they relate to the quiz being fetched. Though the parameter names are self-explanatory, the description adds no semantic value beyond the schema's bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'details for one classic quiz', and specifies key returned fields ('question count and time limit'). This distinguishes it from list_quizzes and other get-details 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?
No guidance is given on when to use this tool versus alternatives like list_quizzes. The description does not mention exclusions, prerequisites, or when a different tool would be more appropriate, leaving the agent to infer usage solely from the name.
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 fully disclose behavioral traits. It only says 'Get a summary' and lists included data points, but does not describe the return format, pagination, potential size, or any side effects. It also doesn't clarify whether any special permissions are needed. The description is minimal and leaves much about runtime behavior 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 essence of the tool. It includes the key resource and scope without unnecessary words. This is an example of concise and well-structured writing.
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 (one parameter), and an output schema is present, so return values are presumably defined there. However, the description lacks any usage context or parameter explanation. Given the absence of annotations and the 0% schema description coverage, the description is adequate for basic calling but incomplete for helping an agent decide when to use it and what to expect beyond the summary list.
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 schema has zero description coverage for the only parameter (course_identifier). The description does not elaborate on the parameter's meaning beyond the phrase 'for a course', which merely repeats the parameter's name. It does not specify allowed formats, examples, or how the identifier is used. The description fails to compensate for the schema's lack of detail.
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 specific resource ('per-student engagement summary'), and the scope ('for a course'). It lists the included dimensions (page views, participations, on-time/late/missing), which distinguishes it from sibling tools like get_assignment_analytics. This is a precise and unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or typical use cases. While the purpose is clear, the agent is left to infer when it should select this tool over the many other read-oriented 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 present, the description carries the full burden of behavioral disclosure. It does add the critical detail that deletion is permanent and irreversible, which is beyond the tool's name. However, it doesn't mention permissions required, whether related content is affected, or any other side effects. For a straightforward delete operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, effectively front-loaded with the action and consequence. Every word earns its place; there is no fluff or repetition. It is exemplary in brevity.
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, the description covers the essential irreversible nature, but it lacks parameter guidance, particularly for page_url. Although an output schema exists, it does not indicate how to construct inputs. An agent would need to consult sibling tools like list_pages to determine the correct page_url format, which is not mentioned. This is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter ambiguity, but it does not. 'course_identifier' and 'page_url' are not described at all. While course_identifier is relatively self-explanatory, page_url is ambiguous (full URL vs. relative path, or how to obtain it). The description adds no meaning beyond the parameter names, leaving the agent to guess the correct format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently delete a wiki page.' It specifies the resource type (wiki page), distinguishing it from other delete siblings like delete_assignment or delete_announcement. It is direct and unambiguous, though it doesn't explicitly contrast with any alternative delete tool, which would have made it a 5.
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 rather than explicit. It is obvious you use this to delete a wiki page, and the warning 'This cannot be undone' serves as a caution but not as a comparison to alternatives. It doesn't say 'use this instead of edit_page_content when you need permanent removal,' leaving some inference to the agent. No exclusions or when-not-to-use guidance are 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that only fields passed are changed, which is a key partial-update behavior. However, it does not mention required identifiers, potential null semantics (the schema allows null), return values, or error conditions. The description provides minimal but essential behavioral insight.
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 deliver the core purpose and the partial-update rule without any redundancy. The information is front-loaded with the primary action first, making it immediately scannable for an agent.
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 main action and the partial-update nuance, which is adequate for a simple edit tool. However, it omits how the page is identified (course_identifier and page_url) and does not clarify whether passing null clears a field, despite the schema allowing null. Given the output schema exists (not shown), some return details may be covered, but the description leaves room for misinterpretation around identifiers and null handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate by explaining parameters. It only references 'title' and 'body' as the fields to be replaced, leaving 'course_identifier' and 'page_url' unexplained. Since these are required to select the page, the description fails to add meaning for two of the four parameters, providing only partial clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Replace' and the resource 'a page's title and/or body', making the purpose unambiguous. It distinguishes from creation and deletion tools by specifying modification of existing content. However, it does not explicitly differentiate from 'update_page_settings', which might be a sibling for other page attributes.
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 the tool: whenever you need to change a page's title or body. It does not explicitly mention alternatives or when not to use it, leaving the routing to the agent's inference. The partial-update note clarifies that only passed fields are changed, which guides usage but does not name 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. It states the action 'Grade' (implying a write operation) and the prerequisite that a rubric must exist, but it does not disclose whether existing grades are overwritten, permissions required, error handling, or any side effects beyond grading. This is a significant gap for a mutation tool with 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?
Two sentences with no filler. The purpose is stated first, followed by precise parameter formats in a compact style. Every sentence adds functional value, 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?
The description covers the core map parameters and a key prerequisite, but it omits the top-level 'comment' parameter and does not differentiate this tool from sibling graders like grade_submission or bulk_grade_submissions. It also lacks explicit behavior about overwriting or idempotency. Given the presence of an output schema (which it need not explain), the gaps are notable but not crippling.
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 description explicitly explains the format for criterion_scores and criterion_comments (keys as criterion IDs, values as points/comment text) and directs the agent to get_rubric for IDs, providing value beyond the schema's generic object types. However, it does not address the 'comment' parameter at all, and since schema description coverage is 0%, the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Grade a submission') and distinguishes it by the use of an existing rubric. It does not explicitly name alternative grading tools like grade_submission or bulk_grade_submissions, but the focus on 'rubric already associated' implies the differentiator.
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 a prerequisite instruction ('get criterion_ids from get_rubric') which guides the calling sequence, but it does not explicitly mention when to choose this tool over sibling grading tools (e.g., grade_submission vs this). The 'already associated' requirement hints at a condition, but it is not explicit about exclusions or alternatives.
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. It states the action (hide grades) but does not disclose side effects, reversibility (beyond the inverse hint), permission requirements, or impact on existing grade visibility. The description is a bare statement without deeper behavioral context, which is insufficient given no annotation support.
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 front-loads the core action and immediately references the inverse relationship. Every word contributes to the meaning, with no fluff or redundancy. It is optimally sized for its content.
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?
Given that there are no annotations, no parameter descriptions, and only a minimal one-sentence description, the definition is not complete for an agent to call the tool confidently. It lacks guidance on when to use it (beyond the inverse hint), parameter specifics, and behavioral nuances. The presence of an output schema covers return values, but the overall context is thin for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. However, it does not mention either parameter (course_identifier or assignment_id) or provide any additional context about their formats or expected values. The parameter names are somewhat self-explanatory, but the description adds no value beyond the schema, leaving all explanation to the agent's inference.
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 ('hide') and resource ('an assignment's grades from students'), explicitly stating the action. It also references the sibling 'post_grades' as its inverse, which distinguishes it from that tool and clarifies its 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 phrase 'the inverse of post_grades' implies when to use it (to reverse a posting action), but it does not explicitly state scenarios, prerequisites, or when not to use it. There is no mention of alternatives or conditions beyond this reference, leaving the usage guidance partially implicit.
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 states that results include due dates and points, but it does not disclose whether the operation is read-only, whether it returns all assignments or only published ones, whether pagination is used, or any permission requirements. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the primary action ('List assignments in a course') and appends the relevant output details. 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?
For a simple list operation with a single parameter and an output schema present, the description is minimally adequate. It conveys the core purpose but omits practical details like pagination, filtering options, or the distinction from similar list tools. Given the broad set of siblings and low parameter coverage, a bit more context (e.g., 'returns all assignments' or 'use for overview') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for parameter descriptions, so the description must compensate. The phrase 'in a course' implies that course_identifier refers to the course ID, adding a little semantic meaning beyond the bare parameter name. However, it does not explain the accepted formats (string or integer) or any constraints. Since the parameter is self-explanatory from its name, the slight addition is enough for a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (assignments), and the scope (in a course). It also specifies the returned content (due dates and points), which distinguishes it from the sibling get_assignment_details (which presumably returns full details for a single assignment) and other list tools. No ambiguity or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for a high-level overview, that more granular details are available via get_assignment_details, or any filtering criteria. An agent would have to infer from the name and context.
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 carry the full burden of behavioral disclosure. The description does not mention that this is a read-only operation, nor does it discuss pagination, output format, or any restrictions. It only states the literal action of listing assignments, adding no insight into side effects or edge cases. This is a significant gap for a tool with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. It earns its place with the specific clarification of 'who's reviewing whom'. However, it is so terse that it lacks useful context like parameter hints, which other dimensions penalize; conciseness itself is good but not exceptional.
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 that an output schema exists, the description need not explain return values. However, it leaves out any mention of parameter requirements (though implied by the name) and provides no behavioral context beyond the basic action. For a simple list tool, this is minimally adequate but lacks details like whether it returns all peer reviews or only those for a specific assignment (though that is implied). It is sufficient for basic use but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines two parameters (course_identifier and assignment_id) with anyOf string/integer types, but the description provides no explanation of these parameters, what they mean, or how they relate to the tool's function. Schema description coverage is 0%, so the description must compensate, but it does not. An agent would have to rely solely on parameter names and the schema, with no contextual guidance.
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 'List' and resource 'peer review assignments', with the scope 'for an assignment' clearly stated. It distinguishes itself from siblings like assign_peer_review and delete_peer_review by focusing on listing existing assignments, and from list_assignments by specifying the peer-review subset. The parenthetical '(who's reviewing whom)' further clarifies the exact data returned.
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: this tool is used when you need to see peer review assignments for a particular assignment. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for an agent to infer typical usage. No exclusions or alternative tools are named, 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only confirms the mutation ('update') without detailing side effects, permission requirements, partial-update semantics, or consequences of null fields. It does not mention that unspecified fields remain unchanged or that the scheduled post date is optional. 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?
The description is a single, efficient sentence that front-loads the action and lists the key fields, with no redundant words. It is appropriately concise for the scope.
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 5 parameters, 2 required, and no annotations, the description is too brief to be complete. It does not explain the required identifiers, the meaning of null values, partial update behavior, or possible side effects. Even though an output schema exists, the description lacks essential usage context for an agent to call the tool correctly. The description fails to provide necessary guidance on how to construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It directly mentions title, message, and scheduled post date (delayed_post_at), but provides no explanation for course_identifier or announcement_id, which are both required to identify the target announcement. It does not clarify that these are identifiers or that only the listed fields are updated. The description only partially compensates for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Update'), resource ('existing announcement'), and lists the modifiable fields ('title, message, and/or scheduled post date'). This distinguishes it from sibling tools like create_announcement or delete_announcement 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for modifying an existing announcement (via 'existing'), but it does not explicitly state when to prefer this over create_announcement, nor does it mention any exclusions or conditions. Lacks explicit when-to-use/when-not-to-use guidance or alternative tool references.
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 the operation type ('List') which implies read-only, but does not mention permissions, side effects, pagination, ordering, or whether archived/deleted topics are included. This is minimal and leaves critical behavior 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, efficient sentence that front-loads the action and resource. It contains no fluff or repetition, and the parenthetical adds a specific qualifier without verbosity. 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?
The tool is simple (one parameter) and presumably has an output schema that defines return values. The description covers the core purpose and the key exclusion. However, it lacks guidance on parameter format, any prerequisites, or behavioral details like pagination. For a simple listing tool, it is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the parameter at all. The parameter name 'course_identifier' is intuitive, but the description adds no extra meaning about expected format (e.g., SIS ID vs internal ID) or constraints. It fails to compensate for the lack of 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 ('List') and the resource ('discussion topics'), and explicitly narrows scope with '(excluding announcements)'. This distinguishes it from sibling tools like list_announcements and list_discussion_entries without opening their schemas. The phrase 'in a course' also identifies the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint of when not to use this tool by excluding announcements, implying that announcements are handled elsewhere. However, it does not explicitly name list_announcements or offer any other alternative tool comparisons (e.g., for topic details or entries). 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.
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 states the action ('post') but does not describe side effects (e.g., creates a record, permission requirements), return values, or how the output schema relates. Nothing beyond the basic mutation is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It avoids unnecessary words, but it is almost too brief, sacrificing completeness for brevity.
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?
Given only 3 simple parameters and an output schema, the description still lacks essential context such as usage distinction (explicit alternative), behavioral expectations, and parameter semantics. It does not fully cover what an agent needs to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only mentions 'discussion topic' and does not explain what message, topic_id, or course_identifier should contain. Parameter names are self-explanatory but no additional semantics or format guidance 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 'post' with a clear resource 'new top-level entry in a discussion topic'. The phrase 'top-level entry' distinguishes it from sibling reply_to_discussion_entry, 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 implicitly signals when to use this tool by specifying 'top-level entry', implying that replies would use a different tool. However, it does not explicitly name the alternative or state conditions like 'use this for new discussion threads, not replies' or mention any prerequisites such as user enrollment.
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?
There are no annotations, so the description carries full burden. It discloses the folder_path default and the local file origin, but does not address overwrite behavior, errors, permissions, or the outcome of a successful upload. 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 two sentences, front-loaded with the primary purpose and then a concise clarification of folder_path. Every sentence adds value with no filler.
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 an output schema, the description lacks essential context about failure modes, file name collisions, or prerequisites (e.g., course must exist). It covers the core action but leaves the agent guessing on operational behaviors that could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for folder_path (destination folder, default root) and clarifies local_file_path via the phrase 'local file (from this machine)'. However, course_identifier is left to its name and context, providing incomplete coverage of all 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 clearly states the action (upload a local file) and the resource (course's Files), and distinguishes from sibling file operations like list_course_files and read_course_file by emphasizing the upload aspect and the local source of the file.
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 use for uploading local files but provides no explicit guidance on when not to use it or which sibling to choose instead. It does clarify the folder_path parameter and default behavior, giving some contextual usage hints, but lacks explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'List' implies a read-only operation, but this is not explicitly stated, and there is no mention of behavior such as sorting, pagination, or rate limits. The description is adequate but minimal, not going beyond the literal action.
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 that states the action and lists the scope options in a compact, front-loaded manner. Every word contributes value; there is no redundant or repetitive 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?
For a simple list tool with one parameter, the description covers the scope options and the output schema is present. It does not mention pagination or ordering, but these are likely covered by the output schema or are not critical for a basic list operation. The description is sufficient for the tool's complexity.
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 only defines scope as a string with a default, but the description provides the full set of accepted values (inbox, unread, starred, sent, archived). This adds essential semantics that the schema lacks, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (Canvas Inbox conversations), and further specifies the scope options. It is distinguishable from the sibling get_conversation_details (which retrieves a single conversation) and send_message (which sends), though it does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_conversation_details or send_message. The scope values are listed but there is no mention of when each scope is appropriate or when another tool should be used 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 full burden of behavioral disclosure. It implies a read-only operation via 'List' and specifies output content (publish status, item counts), but it does not explicitly state that it is non-mutating or mention any caveats such as pagination, permissions, or data freshness. This is adequate for a simple read tool but lacks explicit confirmation of side-effect-free 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 a single, concise sentence that front-loads the key action and details. Every word adds value, with no redundancy or irrelevant information. It is efficiently structured and immediately understandable.
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 one parameter and an available output schema, the description sufficiently covers the essential context: what the tool does and what information it returns. It does not explain optional behaviors like ordering or pagination, but these are not critical for a simple listing tool, especially when the output schema likely provides the return shape.
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 schema description coverage is 0%, so the description must compensate. However, it only mentions 'in a course' which ties to the parameter, but does not elaborate on what course_identifier means, how to obtain it, or any format expectations beyond the schema's anyOf string/integer. The parameter name is self-explanatory, but the description adds minimal semantic value over 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 action ('List modules'), a specific resource ('in a course'), and provides clarifying output details ('with publish status and item counts'). This clearly distinguishes the tool from siblings like get_course_structure or list_courses, as it focuses specifically on modules with additional metadata.
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 guidance on when to use this tool versus alternatives. It does not mention when to prefer list_modules over get_course_structure or any other sibling, nor does it state any conditions or exclusions. The description only describes what it does, not the context for its use.
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 of behavioral disclosure. It does reveal the exact JSON schema for criteria_json, which is crucial for correct input, and mentions the side-effect-free optional association. However, it does not state whether creating overwrites existing criteria, what permissions are required, or what happens if associate_with_assignment_id is omitted (e.g., an ungraded draft). Some context is added beyond the schema, but not enough to fully inform an agent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently paced: it states the purpose in one clause, then dives into the complex parameter with an inline example, and ends with the optional association. The example is verbose but necessary to clarify the JSON shape. No redundant sentences 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 tool has five parameters, one of which is a complex JSON string, and the description covers the most complex one thoroughly. However, it omits guidance on what course_identifier refers to (presumably a course ID from list_courses), and free_form_comments remains unexplained. Since the output schema is present, return values are presumably handled, but the missing parameter semantics leave gaps for an agent trying to call this 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 description adds significant meaning for criteria_json (explaining the exact structure and providing a full example) and briefly explains associate_with_assignment_id. However, it leaves title, course_identifier, and free_form_comments undefined. Since schema coverage is 0%, the description compensates only partially; the three unaddressed parameters are left without semantic guidance beyond their types and defaults.
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 rubric' which is a specific verb+resource and immediately distinguishes the tool from siblings like create_assignment, grade_with_rubric, and post_grades. It also clarifies the optional attach-to-assignment behavior, leaving no ambiguity about what is being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a common use case ('attach it to an assignment for grading immediately') but does not explicitly contrast with grade_with_rubric or explain when to create a rubric standalone versus associating it at creation. There is no when-not guidance or reference to alternative workflows, so the agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool returns the title and body of the front page, implying a read-only operation, but does not mention potential error behavior, authorization requirements, or any side effects. Since it is a simple getter and the return content is specified, a middle score is appropriate; the description is transparent about its core behavior 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, succinct sentence that directly states the action and the data returned. It is front-loaded with the primary purpose and contains no filler. Every word contributes to understanding, making it exemplary in brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers what the agent needs: what the tool does and what it returns. The only gap is the lack of usage guidance relative to the many sibling tools, but that falls under usage guidelines. For a simple getter, the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameter. The description implicitly indicates that 'course_identifier' identifies the course whose front page is requested, but it does not explicitly define the parameter's semantics (e.g., that it is a course ID or the expected format). Given the 0% coverage, the description provides minimal additional meaning beyond the schema's name and type, but is not misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('the course's front page (homepage)'), and further specifies the exact data returned ('title and body'). This clearly distinguishes it from sibling tools like get_course_details (which likely returns broader course info) and get_page_content (which targets arbitrary pages). 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 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. There is no mention of when it is appropriate, when it is not, or any comparison to siblings such as get_course_details, get_syllabus, or get_page_content. The agent must infer context from the description alone, and no exclusions or alternatives are named.
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 adds the meaningful behavioral detail that New Quizzes are excluded, which is useful. However, it does not disclose other behavioral aspects like whether the operation is read-only, pagination, or ordering. The tool is a list operation, but that is not explicitly stated as safe or 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?
The description is two sentences with no wasted words. It front-loads the action ('List classic quizzes') and adds a crucial scope limitation. 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?
Given the tool's simplicity (one obvious parameter) and the presence of an output schema that likely documents return fields, the description covers the core scope. It does not mention pagination or any side effects, but for a list tool this is less critical. It could name the alternative for New Quizzes, but it is otherwise 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?
Schema description coverage is 0%, so the description should compensate. It mentions 'in a course' which implies the course_identifier parameter, but it does not explicitly explain the parameter's meaning or format. Since the parameter name is self-explanatory and the description references 'course', it provides some value, but not much beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists classic quizzes with due dates and points, and explicitly excludes New Quizzes. This gives a specific verb and resource, and the exclusion narrows scope. However, it does not explicitly differentiate from sibling tools like list_assignments, which might also return quizzes, so it lacks full sibling distinction.
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 classic quizzes only by saying 'Does not include New Quizzes,' but it does not explicitly state when to use it over alternatives or name the tool for New Quizzes. There is no guidance on when not to use this tool, only a limitation.
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 does state the tool supports PDF, DOCX, and plain text, and returns extracted text, which is useful. However, it lacks any mention of safety (whether it is read-only), error handling, rate limits, or performance considerations. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with zero filler. It front-loads the primary purpose and then adds a practical note about acquiring the file_id. Every sentence 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?
For a two-parameter tool with an output schema, the description covers the core operation: fetching a file and returning text. It points to a sibling for the prerequisite ID. However, it omits any mention of authentication, error conditions, or whether the operation is read-only. Given the simplicity, this is minimally adequate but not complete.
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 schema has 0% description coverage, so the description must compensate. It explains that file_id can be found via list_course_files, but it does not clarify the purpose or format of course_identifier. The agent is left to guess what course_identifier represents, making the parameter semantics incomplete.
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 'Fetch' with a specific resource ('course file's content') and the output ('return extracted text'). It also implicitly differentiates from list_course_files by mentioning how to find file_id, and from get_page_content because it targets files from a known list of course files.
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 concrete instruction on how to obtain file_id via list_course_files, which implies a prerequisite. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions (e.g., 'use get_page_content for pages'). Usage is implied rather than explicitly routed.
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 high-blast-radius nature and advises double-checking the grades dict, which is valuable. However, it does not cover potential side effects (e.g., overwriting existing grades, atomicity, partial failures) or any error behavior. The warning is there, but depth is 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?
The description is extremely concise, with three sentences that pack purpose, format, and a critical warning. The purpose is front-loaded, and every sentence earns its place. No fluff 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 that this is a high-impact mutation tool with a nested object and an output schema (not shown), the description covers the core semantics and a caution, but lacks details on expected return values, error handling, or confirmation steps. It is adequate for a simple call but not exhaustive for a tool with such blast radius and no annotations.
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 0%, so the description must compensate. It effectively explains the 'grades' parameter format ({user_id: score, ...}) and the 'comment' behavior (applied to every submission). However, it does not explicitly describe 'course_identifier' and 'assignment_id', though these are self-explanatory from names. It adds value to the most complex parameter but leaves others implicit.
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 verb ('Post'), resource ('grades for many students at once on one assignment'), and distinguishes it from the sibling 'grade_submission' (single student) and 'post_grades' (likely similar but the bulk intent is explicit). The format of the grades dictionary is provided, 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 for multiple students ('many students at once') but does not explicitly compare to alternatives like 'grade_submission' or 'post_grades' nor state when not to use it. No exclusions or conditions are provided, so the agent must infer from the name and description.
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 full burden. It states the core behavior (creating an announcement) and the scheduling behavior (delayed_post_at causes it not to post now). However, it does not disclose permissions, reversibility, or side effects beyond the basic mutation. This is moderate transparency 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?
Two sentences, front-loaded with the core action, and each sentence adds distinct value. There is no wasted text, and the scheduling instruction is placed where it matters. Excellent conciseness.
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?
Given the tool has 4 parameters, no annotations, and only a minimal description, it is incomplete. It does not cover parameter semantics, error conditions, or permission requirements. The output schema exists but does not compensate for the missing guidance on when to use and behavioral expectations. It is adequate for a simple action but does not fully equip the agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains only delayed_post_at (that it schedules instead of posting now) but does not explain title, message, or course_identifier. This leaves three required parameters semantically unaddressed, which is a significant gap given the lack of 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?
Description states a clear verb ('Create'), a specific resource ('announcement'), and distinguishes it from siblings like update_announcement, delete_announcement, and list_announcements. It also clarifies a key option (scheduling vs immediate posting), 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 clearly indicates this tool is for creating announcements and provides an explicit usage option for scheduling via delayed_post_at. However, it does not explicitly contrast with alternatives like create_discussion_topic, but the resource is specific enough that context is implied. No exclusions are given, but the purpose is clear.
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 clearly discloses that the deletion is permanent and irreversible ('This cannot be undone'), which is critical for a destructive operation. It also notes that the endpoint handles announcements, adding context beyond the name. However, it omits any side effects (e.g., deletion of associated entries) or permission requirements, but for a delete tool the irreversibility is the key trait.
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, zero filler. It front-loads the action and the irreversible nature, then adds the announcement clarification. Every word earns its place; no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with an output schema present, this description covers the essential context: what it deletes, that it's permanent, and that it also affects announcements. It doesn't discuss side effects on related records, but given the output schema and straightforward nature, this is acceptable. The only missing piece is explicit parameter guidance, already penalized under parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It does not mention course_identifier or topic_id at all. While the param names are self-explanatory from the schema, the description adds no clarity on types, formats, or relationships. This is a notable gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('delete') with a clear resource ('discussion topic') and even clarifies that announcements share the same endpoint, distinguishing it from the sibling delete_announcement. The purpose is unambiguous and ties directly to the tool name.
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 mentions that announcements share the same endpoint, which implicitly suggests this tool can handle both. However, it provides no explicit guidance on when to use this tool versus delete_announcement (a sibling) or any other alternative. There is no when-not-to-use or mention of prerequisites. The inference that this is the 'unified' tool is left to the agent.
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 exist, so the description bears full responsibility. It states the tool returns distribution and rates, implying a read-only operation, which is reasonably transparent. However, it does not disclose any potential limitations (e.g., pagination, course existence requirements) or special behavior beyond the content returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. It efficiently communicates the main output and scope 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 simple read-only tool with one parameter and an output schema, the description is mostly complete. It states what the tool returns and the course context. However, it lacks any guidance on alternative tools or prerequisites, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely says 'for a course,' which adds little beyond the parameter name 'course_identifier.' It does not clarify whether the identifier should be an internal ID or SIS ID, nor the expected format. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (get), a resource (score distribution and on-time/late/missing rates), and scope (every assignment in a course). This distinguishes it from sibling tools like get_assignment_details (single assignment) and get_student_analytics (student-level analytics).
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 it is for aggregate course-wide analytics per assignment, but it does not explicitly mention when to prefer it over alternatives like list_assignments or list_missing_submissions. No exclusions or alternative references are provided, so guidance is only implicit.
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 mentions the excuse behavior, which is useful, but does not explain whether posting a grade overwrites an existing grade, whether score and grade are mutually exclusive, or what happens if both are supplied. It also does not mention any permission requirements or side effects beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It states the primary action in the first sentence, then provides conditional guidance in the second, and the excuse exception in the third. Every sentence serves a distinct purpose, with 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?
While the description covers the main usage scenarios, it leaves some gaps that could lead to incorrect calls. It does not explicitly state that score and grade are mutually exclusive, nor what the interaction between excuse and other parameters is. Given the presence of an output schema, return values are covered, but for a mutation tool with no annotations, more behavioral context (e.g., overwrite behavior) would be expected for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the parameters. It does this effectively for the ambiguous ones: it explains when to use score (points-based) vs grade (pass_fail, letter_grade, percent) and the semantics of excuse. It also implies comment is optional through 'and/or'. This compensates for the lack of schema descriptions, though it does not explain the identifiers (course_identifier, assignment_id, user_id), which are self-explanatory in an LMS context.
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 precise verb and resource: 'Post a grade and/or comment for one student's submission on one assignment.' This clearly distinguishes it from bulk grading (bulk_grade_submissions) and rubric-based grading (grade_with_rubric), so an agent can identify the correct tool without inspecting the schema.
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 explains how to choose between score and grade based on assignment type, which is helpful usage guidance. However, it does not explicitly compare this tool to siblings like bulk_grade_submissions or grade_with_rubric, nor state when not to use it. The phrase 'one student's submission on one assignment' implies scope, but lacks an explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden. It discloses that only top-level entries are listed and that reply counts are included, which is meaningful. However, it omits any mention of read-only nature, permission requirements, pagination, or error handling. For a simple list tool, this is acceptable 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?
A single sentence that is direct, front-loaded with the action, and includes the key nuance (top-level, reply counts) without waste. It is perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with an output schema, the description covers the essential purpose and the important distinction of top-level entries. It does not mention pagination or filtering, but given the simplicity and existence of an output schema, this is nearly complete. It could be improved, but it is quite adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameter roles. It only implies the topic via 'discussion topic' and course context, but never explicitly states what course_identifier or topic_id represent. The agent gets minimal guidance on expected values or types beyond the schema's anyOf, which is insufficient.
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), the specific resource (top-level entries/posts), and the context (in a discussion topic), plus an extra detail (reply counts). This clearly differentiates it from siblings like list_discussion_topics and get_discussion_topic_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving posts in a topic, but does not explicitly mention when to use this tool versus alternatives, nor does it note any exclusions (e.g., not for listing topics). The clear name and purpose make it somewhat obvious, but explicit guidance is absent, so it only earns an implied-level score.
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 the mutation nature and the peer_reviews dependency, which is a genuine behavioral trait not visible in the schema. But it does not state that only provided fields are updated, mention permission requirements, or describe the response shape (relying on the output schema). It adds one meaningful behavior but omits several others.
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, zero redundancy. The purpose is stated first, followed by a single, high-value dependency note. Every word earns its place; it is efficiently front-loaded and easy to scan.
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?
Given 9 parameters and the presence of an output schema, the description is too thin. It lacks guidance on partial updates (whether omitted fields preserve existing values), error conditions, permissions, or how peer_reviews relates to automatic_peer_reviews. While the output schema may cover the return, the description leaves significant gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only offers broad categories ('name, description, points, due date, published state, peer review settings') without mapping to exact property names (e.g., points_possible, due_at, automatic_peer_reviews) or explaining semantics like 'null means no change' or the difference between peer_reviews and automatic_peer_reviews. For 9 parameters, this is insufficient.
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 starts with a clear verb and resource: 'Update an assignment' and enumerates specific fields (name, description, points, due date, published state, peer review settings). This distinguishes it from siblings like create_assignment and delete_assignment, and the mention of 'peer review settings' ties it to assign_peer_review. The purpose is unmistakable.
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?
Provides a concrete conditional: 'peer_reviews=True must be set before assign_peer_review will work on this assignment.' This tells the agent when this tool is a prerequisite for another action. However, it does not explicitly contrast with create_assignment (for new assignments) or note that grade changes belong to grade_submission, so cross-tool guidance is incomplete.
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. It states only that the tool adds an item, without disclosing side effects, permissions, error behavior, or any irreversible consequences. It does not mention what the response looks like, leaving the agent underinformed for a mutating 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 concise—two sentences—and front-loaded with the tool's purpose, followed by conditional field requirements. No filler or redundancy; every sentence 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?
Given the tool's complexity (9 parameters), absence of annotations, and zero schema coverage, the description is insufficiently complete. It leaves ambiguity (e.g., 'most others' for SubHeader) and does not clarify how optional parameters like position or indent behave, nor does it explain the return value despite the output schema existing. The conditional guidance helps but is not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema documentation coverage, the description compensates by clarifying the critical conditional dependencies among item_type, page_url, content_id, and external_url. This is essential information that the schema itself does not convey, so the description adds significant value.
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 ('Add an item to a module') and enumerates the allowed item types, which effectively distinguishes it from sibling tools like create_module or update_module_item. The resource and scope are 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?
Provides useful internal guidance by specifying which parameter to supply for different item types (page_url vs content_id vs external_url). However, it does not explicitly contrast this tool with sibling tools like update_module_item, so the when-to-use vs alternatives is only implied by the tool's name and purpose.
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 explicitly states that the action is permanent ('cannot be undone') and that it also removes associated submissions and grades, which is critical behavioral information for a destructive operation. This is more than a minimal statement but does not cover every possible side effect (e.g., permissions, cascading effects on other entities).
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 and directly states the core purpose and a critical caveat ('cannot be undone'). There is no fluff or repetition; every word adds value. It is front-loaded with the action 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 delete operation with only two parameters, the description covers the destructive nature and irreversibility, which are the most important aspects. It does not describe the output (but an output schema exists, so that is not necessary) nor does it explain parameter usage, but given the low parameter count and the presence of an output schema, the description is mostly sufficient. The missing parameter explanations are a notable gap but not critical enough to lower the score further.
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 schema has 0% description coverage and the description does not explain what course_identifier or assignment_id refer to or how they should be formatted. The description only mentions what the tool does, not what the parameters mean. Since the schema provides no parameter descriptions, the description should compensate but fails to do so, leaving the agent to guess parameter 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 action (permanently delete) on a specific resource (an assignment) and explicitly mentions the impact on submissions and grades. This distinguishes it from other delete tools for different resources (e.g., delete_page, delete_module) without needing to read sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. However, the destructive nature and the fact that it targets assignments imply that it should be used only when an assignment needs to be permanently removed, which is a clear but implicit context.
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 behavioral disclosure burden. It explicitly states 'Permanently delete' and 'cannot be undone,' which is a crucial, non-obvious behavioral trait. However, it does not mention potential side effects like cascading deletion from modules or permission requirements, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the most important information (permanence and irreversibility). There is no wasted wording, and it is perfectly scoped for a simple deletion operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation is simple with a single parameter, and an output schema exists (though not shown), so the description doesn't need to explain return values. It does mention the key caveat (permanence) and the operation itself. It lacks any guidance on preconditions or error scenarios, but for a basic delete, it is reasonably complete.
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 schema has zero description coverage, and the tool description does not explain the 'file_id' parameter at all. The parameter name is somewhat self-evident (an identifier for the file), but the description adds no meaning beyond the schema's basic type definition. It doesn't clarify how to obtain the ID or any format constraints.
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 ('delete'), a specific resource ('course file'), and the critical attribute of permanence. It clearly identifies the operation and is distinct from the many sibling delete tools because it scopes to course files.
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?
While it is obvious which tool to use for deleting a course file, the description gives no explicit when-to-use or when-not-to-use guidance (e.g., 'use this instead of removing a file from a module'). It does not mention alternatives or exclusions, so an agent might not know if there are safer alternatives for non-permanent removal.
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 explicitly states the operation is permanent ('This cannot be undone'), specifies the destructive effect on the module, and clarifies the nuanced consequence that items themselves are not deleted. This adequately exposes the mutating and irreversible nature of the 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 no fluff. It leads with the primary action, immediately emphasizes permanence, and then adds the important nuance about items. Every sentence earns its place and the structure is front-loaded.
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 destructive tool with two obvious parameters and an output schema present, the description covers the essential behavioral context: what is deleted, what is not, and irreversibility. It does not detail error handling or edge cases, but these are not critical for a straightforward delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not — course_identifier and module_id are not mentioned or explained in the description. The parameter names are self-explanatory, but there is no additional semantic detail (e.g., format, how to find the identifier) beyond what the names alone imply.
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 ('Permanently delete a module') and the specific resource ('module'), and it distinguishes itself from sibling tools like delete_page or delete_assignment by clarifying that the module's items are not themselves deleted. The verb is specific and the scope is explicit.
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 the tool (when a module needs to be removed) but does not explicitly contrast it with alternatives or mention conditions like 'use delete_page instead to remove individual items'. There is no explicit when-not-to-use guidance, though the clarity of purpose partially compensates.
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 discloses that the operation is permanent and irreversible ("This cannot be undone"), which is critical behavioral context. It also implies destructiveness. However, it does not discuss potential side effects (e.g., impact on related entities like assignments or grades), authorization requirements, or other operational constraints. The warning about irreversibility is a strong addition, justifying a high 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 exceptionally concise: two short sentences with no filler. The core action is front-loaded, and the critical warning about irreversibility is placed immediately after. Every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two self-named parameters and an output schema, the description covers the most vital contextual element—irreversibility. It does not mention potential failure conditions or prerequisites, but given the straightforward nature of the tool and the presence of an output schema for return values, the missing details are minor. The description is adequately complete for an agent to understand the operation and its key risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (course_identifier, rubric_id). Although the parameter names are self-explanatory, the descriptions are absent. The description does not add meaning beyond the parameter names, nor does it explain how they relate to the operation (e.g., that course_identifier identifies the course containing the rubric). Given the low coverage, the description should compensate, but it does not, resulting in a below-average score.
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 verb and resource: "Permanently delete a rubric." It explicitly identifies that it deletes rubrics specifically, distinguishing it from the many sibling delete tools (delete_page, delete_module, delete_assignment, etc.). The permanence is also highlighted, adding precision.
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 the usage — delete a rubric — but does not explicitly state when to use this tool versus alternatives or provide any exclusions or conditions. It is clear that it's for deleting rubrics, but it lacks explicit guidance on when not to use it or prerequisites, which is typical for delete tools. The purpose is self-evident, but the 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, the description must carry the burden of behavioral disclosure. It does disclose the return content (criteria, point values, rating levels), which is useful. However, it does not state whether this is a read-only operation (though 'get' implies it), what happens if IDs are invalid, or whether pagination or extensive data is involved. It adds value beyond the schema but not a complete behavioral picture.
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 front-loads the action and the returned data, then adds the usage context. There is zero verbosity; 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 get operation with an output schema available, the description covers the essential purpose and use case. It could be improved by mentioning that it complements list_rubrics or how the IDs are obtained, but given the output schema and the simplicity of the tool, it is fairly complete. Nothing critical is missing for a correct call.
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 schema has 0% description coverage, so the description must compensate for parameter meaning, but it does not mention rubric_id or course_identifier at all. The parameter names are somewhat self-explanatory, but the description provides no guidance on how to obtain or format them (e.g., where rubric_id comes from). This is a notable gap given the low 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 action ('Get'), the resource ('a rubric'), and the specific data returned ('criteria, point values, and rating levels'). This distinguishes it from list_rubrics, which would only list rubric summaries, and from grade_with_rubric, which consumes this data. 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 explicitly states a concrete use case: 'needed to build a grade_with_rubric call.' This tells the agent when to use it. It does not explicitly mention alternatives or exclusions, but the single-purpose framing is clear enough; the lack of a comparison to list_rubrics is a minor gap.
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. The verb 'Get' implies a read-only operation, but the description does not explicitly state that no data is modified, nor does it mention any authentication requirements, rate limits, or potential errors. However, for a simple getter with a single identifier and a defined output schema, the implied read-only nature is fairly transparent. It's adequate but could be more explicit.
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 that front-loads the core action ('Get the course's Syllabus body') and appends a helpful navigation hint. Every word earns its place, with no redundancy or fluff. It is optimally concise for a simple getter tool.
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 presence of an output schema covers the return format, so the description need not elaborate. For a single-parameter getter, the description is nearly complete, but it could strengthen transparency by explicitly stating that the operation is read-only and does not modify course data. Given the tool's simplicity, the current description is sufficient, but not fully comprehensive in the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'course_identifier' parameter at all. The parameter name is self-explanatory, and the description's phrase 'the course's Syllabus' implicitly ties it to the course, but no additional meaning is added beyond the schema. The agent must infer that the identifier refers to the course ID. The description should have at least mentioned the parameter's purpose or format to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a well-defined resource ('the course's Syllabus body'), and even includes a navigation path ('Settings > Course Details > Syllabus') that clarifies exactly what data is returned. This unambiguously distinguishes it from siblings like get_course_details or get_page_content, as it targets the syllabus field specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever an agent needs the syllabus body for a course. It doesn't explicitly mention alternatives or exclusions, but the resource is so specific that there's no obvious competing tool among the siblings. It also implicitly communicates that it's a read operation, which is appropriate for a getter. It lacks an explicit 'use this when, not that' statement, so it doesn't achieve a perfect score.
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 must carry the full weight of behavioral disclosure. It does mention the key behavior of distinguishing posted vs delay-scheduled announcements, but it omits other aspects such as pagination, ordering, or any permission requirements. For a simple read-list operation, 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 a single, efficient sentence that is front-loaded with the action and the key distinguishing behavior. There is no wasted language, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essential purpose and the notable nuance. It does not mention pagination or filtering, but those are likely covered by the output schema or are not critical for a basic list operation. Overall, it is complete enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the course_identifier parameter. The description only says 'in a course', which vaguely implies the parameter but does not explain its format, allowed values, or how to obtain it. This is insufficient for a parameter with no 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 ('List') and the resource ('announcements in a course'), and adds a distinguishing nuance ('correctly distinguishing posted vs delay-scheduled') that sets it apart from other list tools. It is immediately obvious what this tool does and how it differs from siblings like list_discussion_topics or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this tool should be used to get announcements with the correct posted vs delay-scheduled status, which implies a specific use case. However, it does not explicitly state when NOT to use it or name alternative tools, so it falls short of the 5-point bar for explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains what is returned (ungraded submissions grouped by assignment) but does not explicitly state that it is a read-only operation or mention any limitations (e.g., no side effects, no grading performed). It also omits details like pagination or ordering, though the output schema may cover return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the core purpose and end with a practical usage hint. Every word earns its place; there is no fluff 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, the description adequately sets expectations about the returned data (ungraded, grouped by assignment) and the intended workflow. With an output schema present, missing details like exact fields or pagination are acceptable. It is reasonably complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter 'course_identifier.' It does not mention this parameter at all. While the parameter name is self-explanatory, the description adds no additional meaning or context about how it is used or what formats are accepted.
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 explicitly states the tool lists every submitted-but-ungraded submission in a course, grouped by assignment. It also frames it as 'the grading queue,' making its purpose immediate and distinct from siblings like list_submissions (all submissions) or list_missing_submissions (missing work).
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 'Start here for what do I need to grade?' clearly indicates the primary use case. It does not explicitly name alternatives or exclusion criteria, but the context implies that other tools handle different listing/grading scenarios. This is clear guidance 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 full burden of behavioral disclosure. It explains the key group_conversation distinction (one shared conversation vs. separate 1:1s), which is a significant behavioral trait. However, it does not mention what happens if subject is null, what course_identifier does, or any side effects like sending emails vs. inbox-only. The most important nuance is covered, but other behavioral aspects are missing.
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, with three sentences split across two clear points: the action and the parameter usage. It front-loads the primary purpose and then adds essential usage details. No wasted words, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main usage (send, group/individual, recipient sourcing) but omits important input details like purpose of course_identifier and subject behavior. Output schema exists, so return values are covered. For an agent to correctly marshal parameters, missing semantics for 2 parameters could cause incorrect calls. While the tool is simple, the description is not fully 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 has 0% description coverage for its 5 parameters, so the description must compensate. It does explain reciprocity_user_ids (comma-separated, from list_users) and group_conversation (boolean effect). However, subject, course_identifier, and body are not described. Body is self-explanatory, but subject and course_identifier remain ambiguous. The description covers the two most critical parameters but leaves others unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a Canvas Inbox message to one or more users.' It specifies the resource (inbox message) and the target (users), and distinguishes itself from sibling tools like create_announcement or post_discussion_entry by focusing on direct messaging. The group vs. individual behavior further clarifies its specific function.
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 guidance: it tells the agent to get recipient IDs from list_users, and explains when to set group_conversation=True vs. False. It implies use for inbox messaging rather than announcements/discussions, but does not explicitly state exclusions. The guidance is clear enough for correct tool selection in most contexts.
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 of behavioral disclosure. It explicitly states 'This cannot be undone', which is a critical warning about irreversibility and destructiveness. This provides the agent with the key safety information needed before invoking the operation. While it doesn't mention permissions or side effects, the irreversible deletion is the most significant behavior for this 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 concise and well-structured. It opens with the primary purpose, immediately follows with parameter format and source, and concludes with the critical irreversible warning. Every sentence adds value, there is no fluff, and the most important information is front-loaded. It is efficiently written.
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 essential points: what it does, how to get IDs, and the irreversible nature. It does not explain the `course_identifier` parameter, which is a gap for an agent trying to invoke the tool correctly. Since an output schema exists, the return format is handled separately. The description is adequate for a bulk delete operation, but the missing parameter explanation prevents it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for both parameters. It explains `announcement_ids` well, including format (comma-separated list) and source (from `list_announcements`). However, it provides no explanation for `course_identifier`, which is required. The agent is left to infer its meaning from the name alone. Since only one of two required parameters is described, the description is incomplete for parameter 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 action ('Delete multiple announcements at once'), identifying the specific verb and resource. It distinguishes itself from the sibling tool `delete_announcement` by emphasizing 'multiple', making the bulk nature obvious. The description is unambiguous and leaves no doubt 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 usage context by instructing the agent to obtain IDs from `list_announcements first`, which is a clear prerequisite. However, it does not explicitly name the alternative `delete_announcement` for single deletions or state when to choose this bulk tool over it. The guidance is implicit but sufficient given the tool name, though it lacks explicit 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 of behavioral disclosure. It correctly implies a read-only operation ('List'), but does not disclose any edge cases, such as pagination, permission requirements, or behavior when no users match. It adds no nuance beyond the obvious read nature, so it is adequate but minimal given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and scope, enumerating the exact filter values with zero redundancy. Every word contributes to understanding, and it is immediately scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which covers return structure), the description does not need to explain response details. It adequately covers the tool's purpose and the main parameter semantics. The only minor gap is the lack of explicit mention of prerequisites (e.g., obtaining a valid course_identifier), but this is implied and not critical for a simple list 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 0%, so the description must compensate. It adds meaning to the enrollment_type parameter by listing all valid values (student, teacher, ta, observer, designer) and clarifies that users are scoped to a course, which partially covers the course_identifier parameter. However, it does not explain the format or possible identifiers (e.g., SIS ID vs. numeric ID), leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List'), a specific resource ('users in a course'), and a distinct filtering dimension ('by enrollment type') with all five allowed values enumerated. This unambiguously differentiates it from sibling tools like list_courses (which lists courses, not users) and other list tools. The purpose is immediately clear without needing to inspect the schema.
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 indicates this tool is for retrieving users of a course and filtering by enrollment type. It implies the need for a course_identifier, likely obtained from list_courses, but does not explicitly state when not to use it or mention alternatives. The context is clear, but there is no explicit exclusion or routing to other 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?
With no annotations, the description carries the full burden. It clearly defines 'missing' as past-due and not submitted, and states the output is grouped by assignment, effectively conveying the operation's behavior. It implies a read-only list operation, though it does not explicitly state read-only status or mention pagination/size concerns. The description adds meaningful 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?
Two sentence definition: the first line states the core action and scope, the second provides a concrete use case. No redundant words, front-loaded with the key purpose. Excellent efficiency and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, a clear purpose, and an output schema (indicated by 'Has output schema: true'), the description covers the essential aspects: it explains what is returned (students grouped by assignment) and the criterion for missing. It does not mention edge cases like assignments with no missing students or whether it includes all course assignments, but these are minor given the output schema and the tool's focused nature.
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 schema has one parameter, course_identifier, with 0% schema description coverage, so the description must compensate. The description fails to mention the parameter at all, offering no guidance on value format (e.g., ID vs. name) or any constraints. The parameter name is somewhat self-explanatory, but no additional semantics are provided, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a precise resource ('students with missing work'), scope ('across all assignments in a course'), and a grouping ('by assignment'). It also includes a concrete query example ('who hasn't turned in X?') that clearly differentiates it from sibling tools like list_submissions (which lists all submissions) and list_ungraded_submissions (which filters on grading status, not missing).
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?
Provides a direct usage scenario ('Use for who hasn't turned in X?'), giving clear contextual guidance. However, it does not explicitly mention when NOT to use it or name alternative tools for overlapping cases (e.g., list_submissions for complete submission data), leaving some inference to the agent. Note: the sibling list is extensive, but the description offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the tool's behavior: extracts readable text from uploaded files, returns typed text/URL for other types, and includes the submission comment thread. It also implies a read-only nature by focusing on fetching data. While it doesn't mention error handling or pagination, it gives a solid behavioral overview expected of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, but the first sentence is dense with information. It front-loads the core purpose and behavior, then adds the usage directive. There is minimal fluff, and each sentence adds value. It is well-structured for quick reading.
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?
Since an output schema exists, the description doesn't need to detail return values. It covers the essential context for using the tool: what it retrieves, how it handles different submission types, and when to use it. It doesn't discuss limitations like unsupported file types or context-specific details, but overall it provides sufficient contextual guidance 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description does not directly explain any of the three parameters (course_identifier, assignment_id, user_id). It implicitly references an assignment and a student, but does not clarify parameter formats, constraints, or how to obtain them. Given the low coverage and lack of explicit parameter explanation, this is a notable gap, though the parameter names are somewhat self-explanatory.
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 phrase 'Pull what a student actually submitted' and clearly identifies the resource (assignment content) and the extraction behavior. It distinguishes itself from sibling tools like list_submissions by focusing on actual content rather than metadata, and explicitly mentions the alternative grading tools it supports.
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 to use this tool before grade_submission or grade_with_rubric, providing a clear when-to-use directive. It names the alternative grading tools that depend on this content, effectively explaining why this tool is the prerequisite. This is direct guidance beyond what the schema or annotations convey.
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 behavioral burden. It discloses that students are notified when grades post and warns against using it as a test. It also explains the graded_only default behavior (only posts graded submissions). These are key behavioral traits. It does not mention reversibility or other potential side effects, but for a grade-posting action, this covers the most important aspects.
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 primary purpose is front-loaded, followed by a concise explanation of the default behavior and a critical warning. Every sentence earns its place; the structure is optimal for quick agent comprehension.
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 only 3 parameters, an output schema present, and a well-explained primary purpose, the description is reasonably complete. It covers the key behavior (releasing grades), the notification side-effect, and the default filtering. While it doesn't mention prerequisites (like having hidden grades first) or any required permissions, these are either implied by the action or covered by the output schema. The description provides enough information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly explains the graded_only parameter: 'graded_only=True (default) posts only submissions that have been graded.' The other two parameters, course_identifier and assignment_id, are not described, but they are self-explanatory given the tool's purpose and their names. The description adds value for the most consequential parameter but does not fully compensate for all parameter meanings.
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: 'Release hidden ("muted") grades on an assignment so students can see them.' It distinguishes the action from other grade-related operations, and the explicit mention of 'hidden/muted' clarifies the unique purpose. The purpose is immediately understandable and not a tautology.
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 grades need to be released (posted) so students can see them. It also includes a caution, 'use deliberately, not as a test,' which implicitly advises against using it for testing. However, it does not explicitly mention alternatives like hide_grades or when NOT to use it, so it lacks explicit exclusions but still offers good 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?
With no annotations provided, the description carries full responsibility for behavior disclosure. It reveals an authentication requirement and that it lists courses, implying a read-only operation. However, it does not mention potential side effects, error conditions, or that it returns data without modification, though 'List' strongly implies non-mutating behavior. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, includes the scope ('enrolled in or teaches'), and contains no filler. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no nested objects) and the presence of an output schema, the description is sufficient. It captures the essential scope and behavior; any return-value details are covered by the output schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage vacuously. Per rubric, 0 params gives a baseline of 4 because there are no parameter semantics to clarify. The description does not need to add anything for 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 states a specific verb ('List') and resource ('all courses'), and clearly scopes it to the authenticated user's enrollments and teaching. It is distinct from sibling tools that operate on course content (e.g., list_pages, list_modules) rather than courses themselves, 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 (when you need the current user's courses) without explicitly naming alternatives. It doesn't include exclusionary guidance, but the sibling set makes it obvious this is the only tool for listing courses. This matches 'clear context, no 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?
With no annotations provided, the description carries the full burden. It clearly states the action and the prerequisite, but does not disclose what happens if the assignment already exists, whether assignments are overwritten, or any error handling. The description is accurate but lacks depth beyond the core 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?
Two concise sentences: the first states the action with all parameters, the second provides a critical prerequisite and references the alternative tool. No wasted words, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple assignment tool with four required parameters and an output schema (not shown but present), the description is complete enough. It covers the purpose, prerequisite, and parameter roles. It does not mention potential error conditions or idempotency, but that is not critical for this straightforward action.
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 0%, but the description clarifies the roles of the parameters by saying 'Assign reviewer_user_id to peer-review reviewee_user_id's submission.' This explains the relationship between reviewer_user_id and reviewee_user_id in a way the schema alone does not. It does not individually document course_identifier or assignment_id, but those are self-explanatory.
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: assigning a specific reviewer to a specific reviewee's submission on an assignment. It specifies the exact parameters involved and distinguishes itself from sibling tools like list_peer_reviews and delete_peer_review by focusing on the assignment action rather than listing or removing.
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 a prerequisite: the assignment must have peer_reviews=True set first, and it points to the update_assignment tool. This tells the agent exactly when it is appropriate to call this tool and directs them to the correct alternative if the prerequisite isn't met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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

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