Canvas MCP Server

by vishalsachdev

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.11.0
Disambiguation3/5
Many tools have overlapping purposes, such as multiple announcement deletion variants (delete_announcement, delete_announcement_with_confirmation, delete_announcements_by_criteria, bulk_delete_announcements) and several discussion-fetching tools (list_discussion_entries, get_discussion_entry_details, get_discussion_with_replies). While descriptions explicitly distinguish many tools, the sheer volume (96) increases the risk of an agent selecting the wrong one.
Naming Consistency4/5
The majority of tool names follow a consistent verb_noun snake_case pattern (e.g., list_assignments, create_page, update_module). However, there is notable variance in verb choice (get vs. list vs. read vs. fetch) and some names carry extra qualifiers (e.g., delete_announcement_with_confirmation, bulk_grade_submissions) that slightly break the predictability.
Tool Count1/5
96 tools is an extreme number, far beyond typical server scopes (3-15). The tool set is highly fragmented with many granular operations (e.g., four distinct announcement deletion tools) suggesting over-engineering rather than a well-scoped surface.
Completeness4/5
The server covers a wide array of LMS features including courses, assignments, discussions, announcements, files, modules, pages, rubrics, peer reviews, analytics, messaging, and accessibility. Notable gaps include missing delete operations for assignments and discussions, and no dedicated single-submission grading tool, but overall lifecycle coverage is strong.
Average 3.8/5 across 96 of 96 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 60 of 61 community issues answered or closed in the last 6 months
- 270 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the read-only nature. The description adds the 'optional reply fetching' behavior, which is useful, but it does not disclose scope (e.g., whether it returns a single topic or all entries), return format, or performance implications. This is minimal but not contradictory.
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 but is under-specified rather than concise. It lacks critical details that would make it useful, making it feel incomplete rather than intentionally brief.
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?
There is no output schema, and the description does not clarify what the function returns—whether it returns a discussion topic with nested replies, a list of entries, or something else. Given the optional reply fetching feature, it should describe the response structure to be usable. The description is insufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (100% coverage). The description's mention of 'optional reply fetching' aligns with include_replies, but it does not add information beyond what the schema states. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'get discussion entries' but does not specify whether it fetches a single entry, all entries, or a discussion topic with replies. It uses the vague word 'Enhanced' and does not differentiate from sibling tools like list_discussion_entries or get_discussion_topic_details, which likely have overlapping functionality.
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?
There is no guidance on when to use this tool versus the many sibling discussion tools. It only mentions 'optional reply fetching' but does not explain the context in which that is beneficial or when alternative tools should be chosen.
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?
The description adds no behavioral context beyond the annotations. Annotations already indicate destructive and non-idempotent behavior, but the description does not explain what happens on conflict, permission requirements, or side effects. No extra transparency is provided.
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, clear, and concise sentence. It uses straightforward language without unnecessary detail, making it 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?
The description is minimal but covers the core action. It does not mention outcomes, such as whether the association overwrites existing data or returns a confirmation, but given the simple nature of the tool and the presence of annotations, it is adequate though not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for all parameters are complete and precise. The tool description does not add any additional meaning beyond what the schema already conveys. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: associating an existing rubric with an assignment. The verb 'associate' is specific and distinguishes this tool from creation or listing tools like create_rubric or list_rubrics.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios (e.g., when an association already exists), or why one might prefer this over creating a new rubric.
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?
The description adds no behavioral information beyond what the annotations already convey. Annotations state idempotentHint=false and destructiveHint=false, but the description does not disclose side effects (e.g., publishing by default), permission requirements, or whether the module is created in a draft state. The wording 'create' implies mutation but offers no further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the purpose. There is no superfluous text, and the core action is front-loaded. It avoids redundancy with the tool name and schema details.
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 no output schema, and the description does not explain what the API returns upon success (e.g., the created module's ID or details). Given the tool's role in a larger module workflow, the description does not cover the expected outcome or any error conditions. The schema is rich, but the description leaves the agent without guidance on how to handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description makes no mention of parameters or their implications, relying entirely on the schema. It does not add any value beyond what the property descriptions already provide, such as defaults or formatting for unlock_at.
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 'Create a new module in a course' clearly identifies the action (create) and the resource (module) within a course. It is distinct from sibling tools like update_module, delete_module, and list_modules by the verb, but it does not explicitly contrast itself with alternatives, which prevents a perfect score.
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 other module-related tools. There is no mention of prerequisites, when creation is appropriate, or how it differs from update_module or add_module_item. The instruction is minimal and leaves the agent to infer the use case.
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?
The readOnlyHint annotation communicates that the tool does not modify state, and the description adds no behavioral detail beyond that. 'Create' suggests output generation rather than a pure read, but it does not contradict readOnlyHint; no additional side-effect, permission, or output-format behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core purpose and contains no filler. It is appropriately concise, even though other dimensions lack depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report-generation tool with no output schema, the description is too sparse. It does not explain what the report contains, how report types differ, what formats map to, or when this should be chosen over the many sibling analytics and report tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds no extra meaning beyond the schema, and it does not clarify how report_type, format_type, or include_student_names interact for different report variants.
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 ('Create'), a concrete resource ('reports on peer review quality'), and a target audience ('instructor-ready'). It is clear, though it does not explicitly differentiate itself from sibling tools like generate_peer_review_report or analyze_peer_review_quality.
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 related peer-review reporting or analytics tools. The description implies its use for instructor-facing feedback reports, but it does not state exclusions, prerequisites, 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?
The description adds no behavioral context beyond the annotations, such as what content may be overwritten or whether the update is partial. The idempotentHint and destructiveHint are already present in annotations, but the description itself does not disclose side effects. It merely restates that the operation updates an existing resource.
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 redundant content. It communicates the core purpose efficiently, although it is terse.
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 10 optional parameters and a destructiveHint, the description is insufficiently complete. It does not explain the PATCH-like behavior that only provided fields are updated, nor the side effects of unpublishing/locking or deleting content. The lack of an output schema means the description could have clarified expected behavior, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 10 parameters documented by name and meaning. The description itself adds no parameter semantics, so it relies on the schema. Per the baseline for full schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as updating an existing discussion topic or announcement, using a specific verb and resource. It distinguishes from sibling tools like create_discussion_topic and delete_announcement. However, it does not enumerate the updatable fields, so it stops short of a fully detailed purpose.
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 usage guidance is provided. The description does not state when to use this tool versus create_discussion_topic or delete_announcement, nor does it mention prerequisites. The only implied context is that the resource must already exist, which is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate idempotentHint=false and destructiveHint=false, but the description adds no further behavioral context such as side effects, permission requirements, or consequences of duplicate calls. It simply states the action without elaborating on what happens upon creation.
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, clear sentence with no unnecessary words. It is well-structured and directly to the point, making it easy to parse.
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 (14 parameters, many optional), the description does not explain the effects of omitted parameters, default behaviors, or how the assignment interacts with other course elements. It lacks context about the impact of setting fields like 'published' or 'grading_type', leaving the user without enough information to anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all 14 parameters (100% coverage), so the baseline is 3. The tool description does not add any clarification beyond the schema's own terse parameter descriptions, leaving the meaning of fields like 'assignment_group_id' or 'allowed_extensions' to the user's interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new assignment in a course.' It specifies the resource (assignment) and the context (course), distinguishing it from other tools like 'update_assignment' or 'create_discussion_topic'.
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?
The description provides no guidance on when to use this tool versus alternatives such as 'update_assignment' or 'create_announcement'. It does not mention any prerequisites, typical scenarios, or conditions that would make this the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description's 'Analyze' wording is consistent with a read-only operation. The description adds the scope of analysis ('quality and content') but does not disclose report generation behavior, output format, or any other execution traits 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 front-loaded sentence with no redundant or filler content. It is concise, though slightly terse given the tool's four parameters and the absence of an output schema.
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 no output schema and sits among many closely related peer-review tools, but the description does not explain what the analysis returns, how generate_report affects behavior, or how analysis_criteria customizes results. This leaves significant gaps for an agent deciding how to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented. The description adds no semantic detail about course_identifier, assignment_id, analysis_criteria, or generate_report, so it does not exceed the baseline established by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and resource ('peer review comments') to convey a clear read-only analysis action, including the dual object of 'quality and content.' However, it does not differentiate from overlapping siblings like get_peer_review_comments or identify_problematic_peer_reviews, which likely analyze similar data.
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 about when to use this tool versus alternatives such as generate_peer_review_report, identify_problematic_peer_reviews, or get_peer_review_comments. The description states only what the tool does, not when it should be preferred or excluded.
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?
The description says 'create a new page,' which implies a non-destructive action, yet the annotations declare destructiveHint: true. This is a direct contradiction. The description also adds no extra behavioral context beyond the annotations, such as side effects or whether existing pages could be affected. Per the rubric, a contradiction mandates a score of 1.
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 efficiently conveys the core purpose. There is no wasted text or redundancy, making it easy for an agent to quickly parse the intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but it has six parameters and no output schema. The description does not mention what the response contains (e.g., the created page ID) or any nuances like the effect of setting front_page or published. While the schema covers the parameters, the description could be more helpful by noting optional configuration or expected return behavior. It meets the minimum viability but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented with descriptions (e.g., 'HTML content for the page', 'Whether to publish'). The description text itself adds no additional parameter semantics or usage examples, but since the schema fully covers the parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (page) in a specific context (Canvas course). It unambiguously distinguishes this from sibling tools like edit_page_content, delete_page, and update_page_settings, which have different verbs or resources.
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 when to use create_page vs edit_page_content or bulk_update_pages. It also does not mention prerequisites like required permissions or the need to specify a course_identifier beyond what the schema already states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation is consistent with the export description, so no contradiction. However, the description adds minimal behavioral context beyond the annotation—it does not disclose file output behavior, default anonymization, or whether the tool returns data directly. The scope 'all peer review data' is a useful addition.
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 redundant content. It is front-loaded with the action ('Export') and communicates the core purpose efficiently.
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, no output schema, and many peer-review siblings), the description is too terse. It does not specify what 'all peer review data' includes, how the export is delivered (file vs. data), or when this bulk export is appropriate. The absence of an output schema places more burden on the description, which it does not satisfy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions, so the baseline is 3. The description's 'various formats' vaguely anticipates the output_format parameter but adds no syntax or default details beyond what the schema already provides.
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 (export), resource (all peer review data), and purpose (for analysis). It implies a bulk extraction tool, which distinguishes it from siblings like get_peer_review_comments or generate_peer_review_report, though it does not explicitly name those 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 explicit guidance on when to use this tool versus the many peer-review sibling tools. The phrase 'for analysis' hints at a use case but does not state exclusions or mention alternatives such as get_peer_review_completion_analytics or generate_peer_review_report.
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?
The annotation already indicates readOnlyHint: true, so the description adds no additional behavioral context such as side effects, permissions, or rate limits. The description is purely functional and does not disclose any traits beyond the annotation.
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, clear sentence that is concise and to the point. It is front-loaded with the main action and resource, making it easy to understand without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a simple getter. It does not specify the structure or details of the TODO list, and there is no output schema to rely on. However, given the context of similar tools, the term 'TODO list' is likely sufficient for a user to understand the return value.
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 tool has no parameters, and the schema coverage is 100% (since no parameters are needed). The description does not need to explain parameters, and the baseline for high schema coverage is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the user's Canvas TODO list. The verb 'Get' and resource 'Canvas TODO list' are specific, and it is distinct from other sibling tools like get_my_upcoming_assignments 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or comparisons with other tools that might also retrieve task-related information.
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 indicate destructiveHint: true)Skip. The description simply says 'Edit the content' without explaining that it overwrites existing content or any side effects. Since the annotation already signals destructiveness, the description doesn't contradict, but it also doesn't add specificity about the nature of the edit.
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 and uses a standard verb-object structure. It clearly states what is edited and the target, but lacks any additional structure like examples or return details.
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?
No information about side effects beyond the annotation, no edge cases, no prerequisites (e.g., user permissions). Minimal context is provided; the tool is simple but could mention that content is replaced entirely.
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?
All parameters are described: course_identifier (code or ID), page_url_or_id (slug or ID), new_content (HTML), and optional title. Descriptions are clear enough, though no examples or constraints beyond types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Edit the content of a specific page.' It identifies the resource (page) and the action (edit content), but it does not explicitly differentiate from sibling tools like 'update_page_settings' or 'bulk_update_pages', though the focus on content (HTML) and singular page implies difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as update_page_settings or create_page. It does not mention scenarios where it is inappropriate or any 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?
The annotation readOnlyHint: true already indicates this is a safe read operation, so the description doesn't need to repeat that. However, it adds no behavioral context beyond the annotation—no mention of rate limits, response format, or that no changes occur. Given the annotation covers the safety profile, a score of 3 is appropriate as it adds minimal value.
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?
Extremely concise—a single sentence with no redundancy. It states the purpose without fluff. Perfectly front-loaded and efficient.
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 no output schema, so the description should explain what 'detailed information' includes to help the agent set expectations. It also lacks differentiation from sibling tools that retrieve course-related data (e.g., syllabus, content overview). The single parameter is simple, but the absence of return details and usage context makes it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter (course_identifier) with a clear description and type. Since schema coverage is 100%, the description doesn't need to add parameter details. The tool description adds no extra meaning about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'course', and indicates it returns 'detailed information'. It distinguishes from siblings like get_course_structure or get_syllabus by being generic, but could be more specific about what 'detailed information' includes. Still, it is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as get_course_structure, get_syllabus, or get_course_content_overview. The description only states what it does, not the context or criteria for selection. Missing exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already conveys that this is a safe read operation. The description adds minimal behavioral context by specifying that it returns comment text for peer reviews, but it does not disclose return shape, pagination, or effects of the boolean options beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to stating the tool's core function.
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 no output schema, six parameters, and many sibling peer-review tools, the one-sentence description is insufficient. It does not explain what the returned data looks like, how the include/anonymize options affect output, or how this tool differs from similar peer-review tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds no additional parameter-level meaning beyond the assignment scope already evident from the schema, placing it at the 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 uses a specific verb ('Retrieve') and identifies the exact resource ('actual comment text for peer reviews on an assignment'). It clearly conveys the tool's purpose, though it does not explicitly contrast with closely related peer-review tools like list_peer_reviews.
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 such as list_peer_reviews, get_peer_review_assignments, or generate_peer_review_report. The description only states what it does, with no exclusions or contextual recommendations.
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 provide readOnlyHint=true, and the description does not contradict this—'flag' likely means identify in a read-only manner. However, the description adds minimal behavioral detail beyond the annotation, such as what constitutes 'problematic' or the output format.
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, direct sentence with no wasted words, efficiently conveying the core purpose.
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 description is too terse for the complexity of flagging criteria. It lacks details on what defines 'problematic', how criteria are applied, or what the output/results look like, especially with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The tool description adds no additional semantics beyond the schema, including no clarification of the 'criteria' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: flagging reviews that may need instructor attention. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like 'analyze_peer_review_quality' or 'get_peer_review_completion_analytics'.
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. There is no mention of context, prerequisites, or situations where other review analysis tools would be more appropriate.
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 include readOnlyHint=true, which covers safety. The description adds minimal context beyond that, such as the requirement for a course identifier, but does not disclose potential large result sizes, rate limits, or that it only returns basic user info. With annotations present, the description meets the baseline but does not add much.
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, clear sentence with no wasted words. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter nature and the readOnlyHint annotation, the description is adequate but lacks mention of what exactly is returned (e.g., names, IDs, emails), which could be important for an agent. No output schema exists to fill that gap, so some completeness is lost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented. The description adds no further semantic detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists users in a specific course, using a specific verb ('List') and resource ('users'). It is distinct from siblings like 'list_courses' and 'get_course_details, though it does not explicitly differentiate from 'list_submissions' or 'list_groups', which are clearly different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention filtering options, pagination, or whether it requires specific permissions or course roles. Context is implied only by the 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?
Annotations already indicate idempotent and destructive behavior. The description adds a note about permanence and potential recycle-bin retention, which provides extra context but does not go into detail about the safety checks or failure modes.
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, consisting of two short sentences with no redundancy or unnecessary details. It efficiently conveys the core action and a key consequence.
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 basic action and permanence but lacks information on the confirmation process, outcomes of dry-run, or error handling. Given the lack of an output schema, more context on behavior would be beneficial, but the description is not misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters, achieving 100% coverage. The tool description does not add any additional semantic meaning beyond what the schema already explains, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an announcement and mentions optional safety checks, which adds some specificity. However, it does not explicitly differentiate from the sibling 'delete_announcement' tool, which could cause confusion.
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 'delete_announcement' or 'bulk_delete_announcements'. It lacks context on scenarios where confirmation or safety checks are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds useful context about the report contents. However, it does not mention that saving to a local file is possible via save_to_file, nor does it clarify that this is a consolidated read-only report combining data from other tools. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main action and lists the key inclusions without any filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a read-only report generator with fully documented parameters, but the tool has no output schema and sits among many closely related siblings. The lack of explicit sibling differentiation and return-structure detail leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are already individually documented. The description adds no parameter-specific meaning beyond the general report contents, so it meets the baseline without exceeding it.
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?
Description uses the specific verb 'generate' with the resource 'peer review completion report' and lists the key contents: summary, analytics, and follow-up recommendations. It is clear and actionable, though it does not explicitly distinguish itself from sibling tools like 'generate_peer_review_feedback_report' or 'get_peer_review_completion_analytics'.
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, and it does not name any sibling tools. Given the large number of peer-review-related siblings, the agent is left without help deciding between this consolidated report and the more specific analytics/follow-up 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?
Annotations include readOnlyHint=true, so the description doesn't need to disclose read-only behavior. The description adds that it returns the user's own submission statuses, implying personal scope, but doesn't mention edge cases like missing submissions or empty results. Given the annotation already covers safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that clearly states the action and scope. No fluff, no redundant information. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and a read-only annotationcars. The description is adequate for a basic status retrieval, but it doesn't differentiate from 'get_my_submission' or clarify what 'status' includes (e.g., graded, submitted, late). Given the lack of output schema, a bit more detail on the returned statuses would improve completeness, though it's not critically lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the only parameter (course_identifier) already has a description in the schema ('Course code or Canvas ID (omit for all courses)'). The tool description doesn't add any additional parameter details, so it relies entirely on the schema. Baseline 3 is warranted.
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 'Get your submission status for assignments' clearly specifies the verb (get) and resource (submission status for assignments). It distinguishes from siblings like 'get_my_submission' (which likely retrieves full submission details) and 'list_submissions' (which might be broader). However, it doesn't specify what statuses are included, leaving slight ambiguity around the scope of 'status'.
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 similar alternatives like 'get_my_submission' or 'list_submissions'. It states the purpose but does not mention exclusions, prerequisites, or when not to use it. This is a significant gap for an agent choosing among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, and the description does not contradict this. It adds minimal context by indicating the output includes a mapping with completion status, but does not explain details like whether pagination is involved, how completion is determined, or any additional side effects. Since annotations already cover safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose without unnecessary detail. It is well-structured and front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the abundance of sibling peer-review tools, the description is somewhat sparse. While the schema and annotation provide structural safety, the description does not clarify what distinguishes this mapping from list_peer_reviews or analytics tools, leaving potential ambiguity. However, for a straightforward read-only operation, it may suffice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add clarification beyond the schema; it mentions 'completion status' but that likely refers to output, not parameters. No parameter-specific guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a peer review assignment mapping, specifying the resource (peer review assignments) and the key aspects (who reviews whom, completion status). However, it does not differentiate from sibling tools like list_peer_reviews or get_peer_review_completion_analytics, which may serve similar purposes.
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 the many peer-review-related siblings. The description lacks any mention of preferred use cases, exclusions, or alternative tools, leaving the agent to guess which mapping tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, and the description's 'Get' is consistent. The description adds only output composition (student-level breakdown, summary stats) but no additional behavioral context such as permission requirements, default filtering behavior, or response limitations.
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 uses every word effectively. It states the verb, resource, and key output characteristics 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?
With no output schema, the description gives only a vague sense of the return shape ('student-level breakdown and summary stats') and does not clarify how the boolean parameters alter the output. However, the parameter schema is complete, and the tool is relatively simple, so the description is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds no extra parameter semantics or relationships beyond what the schema provides, making the baseline 3 appropriate.
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 ('Get') and resource ('peer review completion analytics') with an output qualifier ('student-level breakdown and summary stats'). It is specific enough to distinguish from most siblings, though it does not explicitly differentiate from the similarly named 'generate_peer_review_report'.
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 about when to use this tool versus alternatives. With many peer-review sibling tools present, the description does not state exclusions or direct the agent to a better tool for other analytics needs.
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 only readOnlyHint provided, the description adds no behavioral detail beyond the tool name: it does not mention whether page content is included, whether results are paginated, or what the returned page summaries look like. It is not misleading, but it fails to provide context beyond the annotation.
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 conveys the essential purpose with no unnecessary words. The structure is ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only list operation, and the schema covers parameters. However, with no output schema, it does not explain what information is returned (metadata vs. content) or note pagination behavior, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters with 100% coverage, including defaults for sort, order, and filter semantics. The description itself adds no parameter-level detail, so the schema carries the full burden; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List pages for a specific course' clearly identifies the action (list) and resource (pages) with a scoping constraint (course). It is distinct enough from sibling tools like get_page_details and get_page_content, though it does not explicitly differentiate itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: when you need to list pages for a course. However, there is no explicit guidance about when to prefer this over get_page_details, get_page_content, or list_courses, and no alternatives or exclusions are mentioned.
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 readOnlyHint=true, the annotation already covers the safety profile. The description adds that it lists 'all' peer review assignments, implying a comprehensive result set, but does not disclose pagination, ordering, or response structure. This adds minimal context beyond the annotation, meriting a mid-range 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 a single clear sentence with no redundant information. Every word contributes to the meaning, making it exceptionally concise and 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?
Given the absence of an output schema, the description could have elaborated on the return format or clarified the distinction from similar sibling tools. The description is functionally adequate but leaves some ambiguity in a rich context of peer-review tools, so it falls short of being 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 input schema provides 100% coverage with descriptions for both parameters ('Canvas assignment ID' and 'Course code or Canvas ID'). The description does not add additional meaning beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('peer review assignments') with a scope ('for a specific assignment'). It effectively conveys what the tool does, though it does not explicitly distinguish it from similar sibling tools like 'get_peer_review_assignments' or 'get_my_peer_reviews_todo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many peer-review-related siblings. There is no mention of alternatives, prerequisites, or scenarios where this tool is preferred. The intended usage is only implied by the action itself.
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?
The description adds no behavioral details beyond the annotations. While annotations indicate idempotent and destructive behavior, the description does not explain what happens during the update (e.g., partial updates, return value, side effects). Thus it offers minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, directly stating the purpose without unnecessary words or redundancy. It is efficiently 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?
The description is minimal but covers the core action. However, it omits details such as whether unspecified fields remain unchanged, whether the operation returns the updated item, or any error conditions. Given the tool's simplicity, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 12 parameters, and the tool description does not add any interaction context or meaning beyond those individual descriptions. Since schema coverage is 100%, the baseline is 3; no added value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and the resource (module item), distinguishing it from sibling tools like create_module_item or delete_module_item. It is unambiguous and specific.
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, nor does it mention prerequisites (e.g., needing module_id and item_id) or expected outcomes. It is a bare statement with no contextual usage instructions.
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 indicate destructive and non-idempotent behavior, which the description does not contradict. However, the description does not add extra context about side effects, such as that grades will be permanently changed or that concurrent processing may have race conditions. Given the annotations already cover the destructive nature, the description provides minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It avoids redundancy and includes only essential information about the tool's function and approach (concurrency and batch processing). This is an optimal length for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and mentions concurrency, which is a key operational detail. It does not explain error handling or partial failures, but that is not strictly necessary. Given the rich parameter descriptions in the schema, the description is sufficiently complete for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema, so the description does not need to explain them. The description adds no extra semantic details beyond what the schema already provides (e.g., the structure of 'grades' dict). Since schema coverage is 100%, the baseline is 3, and the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: grading multiple submissions efficiently and in batches. It distinguishes itself from single-submission grading tools by mentioning 'bulk' and 'concurrent processing,' though it could further clarify that it handles grading for an entire assignment at once.
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 does not explicitly state when to use this tool versus alternatives like 'grade_with_rubric' or 'assign_peer_review.' It implies bulk usage through 'multiple submissions' and 'batches,' but lacks explicit guidance on scenarios (e.g., when grading many students at once) or when to prefer it over other grading 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?
Annotations declare readOnlyHint=true, so the agent already knows it's a safe read operation. The description adds 'detailed information' but doesn't disclose what fields or scope are included (e.g., does it include submissions, rubric, grading status?). No contradiction exists. With annotations covering the safety profile, the description contributes moderately but doesn't specify return payload details or any side effects (which are unlikely given read-only).
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?
Single sentence, entirely front-loaded, with no wasted words. It doesn't use bullet lists or extra details, but for a simple getter, this is appropriately concise. Minor deduction because it doesn't add a usage hint that could fit naturally, but the structure is clean.
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 it's a read-only detail fetcher with a very small schema and no output schema, the description is the only prose guidance. It tells you what it does (get details) but not what 'details' means (which fields are returned). This is a minimal viable description: it doesn't confuse the agent, but the agent might not know if this returns, e.g., due date vs submissions. Sibling tools like 'get_my_submission_status' or 'get_assignment_analytics' overlap in context, so a bit more detail could help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described ('Canvas assignment ID' and 'Course code or Canvas ID'), so the schema already carries the main semantic weight. The description doesn't add further context about how the parameters relate or whether they must match a specific course. Baseline 3 is appropriate when schema fully documents parameters.
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 'Get detailed information about a specific assignment' clearly identifies the action (get) and the resource (a specific assignment), and the definite article and 'specific' indicate it is a detail-fetching tool rather than a list tool. It doesn't explicitly distinguish from siblings like 'get_assignment_analytics' or 'get_my_submission_status', but the combination of 'details' and 'assignment' is reasonably specific in 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 implies this is for fetching details for a specific assignment, but it doesn't provide explicit when-to-use vs alternatives. The sibling list includes 'list_assignments' (which likely provides overviews) and 'get_assignment_analytics' (which suggests analytics), so a statement about when to choose this over those would improve clarity. No explicit exclusions are given, but the 'specific assignment' phrasing suggests it's not for listing or aggregating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds a useful scoping detail (including all replies) but does not address authentication, rate limits, or other behavioral aspects. Given the annotation, the bar is lower, and this modest extra context justifies a score of 3.
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 conveys the essential purpose without unnecessary words. It is well-structured for easy digestion.
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 no output schema, the description should give a clearer idea of what 'detailed information' includes (e.g., author, timestamps, replies as objects). The phrase 'including all its replies' provides some hint, but it remains vague about the exact return structure, leaving incomplete context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three required and one optional parameter, achieving 100% coverage. The tool description does not add any additional meaning beyond what the schema already conveys, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific discussion entry and includes all its replies. This distinguishes it from sibling tools like listing entries or getting topic details, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to use this tool over alternatives such as list_discussion_entries or get_discussion_with_replies. While the scope is implied, there is no explicit guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds no further behavioral context (e.g., pagination, whether it returns only published assignments, or performance considerations). With annotations covering the safety profile, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, making it easy to parse and retain.
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, no output schema, and a read-only annotation, the description is sufficient. It states the resource and the required identifier without over-explaining. However, it does not mention what information the listing includes (e.g., due dates, status), but that is likely covered by the tool's implicit function.
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 coverage is 100%—the parameter 'course_identifier' is described as 'Course code or Canvas ID.' The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists assignments for a specific course, with a verb and resource. However, it does not differentiate from sibling tools like list_submissions or get_my_upcoming_assignments, which also deal with assignments but have different scopes.
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 get_my_upcoming_assignments or list_submissions. The description only implies a course is needed, but does not clarify scenarios like fetching all assignments for a course vs. user-specific or submission-related lists.
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 provide idempotentHint=false and destructiveHint=false, which are minimal. The description adds no behavioral context beyond the action itself—no mention of permissions, whether the reply is visible immediately, or any side effects. With sparse annotations, the description could have added more, but it doesn't contradict them.
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. No wasted words, but it could have added a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with full schema coverage and no output schema, the description is adequate but not complete. It doesn't explain what happens after replying (e.g., confirmation, visibility) or any prerequisites like needing the entry_id from a prior call. Given the tool's simplicity, this is acceptable but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented in the schema. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
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 student's discussion entry/comment') with a specific verb and resource. It distinguishes from siblings like post_discussion_entry (which creates a new entry) and get_discussion_entry_details (which reads), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (replying to a student's entry) but provides no explicit guidance on when to use this vs. post_discussion_entry or other discussion tools. No exclusions or prerequisites are mentioned.
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?
The annotations already flag destructiveHint=true and idempotentHint=false, so the description's statement that deletion is 'Permanent' adds meaningful context beyond the structured annotation. It also mentions the nuance that Canvas may retain a recycle-bin copy depending on admin settings, which is a helpful behavioral caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and is immediately front-loaded with the core action. The second sentence adds relevant destructiveness context without padding or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a destructive multi-parameter tool and no output schema, the description is adequate but not fully complete: it conveys permanence and criteria-based selection, while the schema covers parameters. Missing context includes when to prefer this over sibling delete tools and what the tool returns or does on dry_run, so the overall description is acceptable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters including criteria keys, limit, and dry_run. The description does not add parameter-level semantics beyond saying 'specific criteria,' so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Delete announcements') and a specific selection mechanism ('matching specific criteria'), so the tool's purpose is obvious. However, it does not explicitly differentiate itself from the sibling tools delete_announcement, bulk_delete_announcements, or delete_announcement_with_confirmation; the distinction is mostly left 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 gives no guidance on when to use this tool versus alternatives such as delete_announcement or bulk_delete_announcements, and it does not mention any prerequisites or exclusions. The only implied usage is that it operates on multiple announcements by criteria, which is also apparent from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the destructive and irreversible nature ('Permanent — Canvas may retain a recycle-bin copy'), which adds context beyond the annotations (destructiveHint=true, idempotentHint=true). It does not contradict annotations, so transparency score is neutral. It could have warned about authentication requirements or cascading effects, but the note about recycle-bin shows partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and the most important info (permanence) is front-loaded. Every word is useful.
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 the tool is a simple delete operation, the description covers the necessary behavior. However, it doesn't mention what happens to associated resources or whether confirmation is required. Since there's no output schema, a note on return values could enhance completeness, but it's not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has high coverage (100%) with clear parameter descriptions ('Page URL slug or page ID to delete', 'Course code or Canvas ID'). The description does not add additional semantics beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a page') and the resource ('from a Canvas course'). It distinguishes itself from sibling tools like update_page_settings or bulk_update_pages by specifying the destructive action. The additional note about permanence adds important context.
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 does not specify when to use this tool versus alternatives. It doesn't mention that require_title_match can be used as a safety check to avoid accidental deletion, or that alternatives like bulk_delete_pages or soft-delete methods might exist. No exclusions or preconditions 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?
Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds that the list is prioritized and focused on follow-up, but it does not explain how priority is determined or what behavioral details apply beyond a read-only list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core purpose efficiently.
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?
There is no output schema, so the description should clarify return contents; it only says 'list of students.' Required parameters are documented in the schema, but priority semantics and output fields are unspecified. This is adequate for basic selection but 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific detail beyond the schema; 'prioritized' loosely aligns with priority_filter but does not explain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a concrete resource: 'prioritized list of students needing follow-up on peer review completion.' This clearly distinguishes it from sibling tools like get_peer_review_completion_analytics and generate_peer_review_report.
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, and it does not mention exclusions or related tools. The use case is only implied by 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?
Annotations include readOnlyHint=true, so the description doesn't need to repeat that. The description adds minimal behavioral context (authenticated user scope) but doesn't disclose details like pagination, ordering, or what 'current active' means. No contradiction found, and the annotation covers safety.
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, clear sentence with no filler. It is front-loaded and efficient, conveying the essential purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with good annotations and full param schema coverage, the description is adequate. However, it doesn't mention return format or any implicit behaviors like default scope (active enrollments), which the parameters imply. Given the sibling tools, a bit more context about scope filtering could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, both parameters have descriptions in the schema. The tool description doesn't add extra meaning beyond what the schema provides, so the baseline 3 applies. It could have explained how the flags interact (e.g., include_all vs include_concluded).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists courses for the authenticated user, which is a specific verb+resource combination. It distinguishes from siblings by focusing on the user's own course list, though it could more explicitly differentiate from 'get_my_enrollments' or other listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving courses the user is enrolled in, but doesn't explicitly state when to use this versus alternative tools like get_my_enrollments or list_assignments. No exclusions or references to alternatives 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?
The annotation readOnlyHint: true already conveys that the operation is read-only. The description does not add extra behavioral details (e.g., side effects, required permissions) but is consistent with the annotation.
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, clear sentence with no superfluous words. It is optimally concise and 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?
The description is adequate for a simple listing operation but does not specify the return format or any additional context. Given the rich sibling tool set, a bit more detail could be beneficial, but the core meaning is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters (course_identifier and assignment_id), meeting the 100% coverage baseline. The tool description does not add further semantic clarification beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (submissions) and specifies the context (a specific assignment). It is unambiguous and directly conveys the tool's purpose.
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 alternative tools like list_assignments or list_discussion_topics. It lacks any indication of scenarios or preferences.
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 include readOnlyHint: true, which already communicates the read-only nature. The description adds no further behavioral details beyond 'scan', such as what constitutes 'basic' issues, whether it modifies anything, or what the output format is. It doesn't contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the tool's function. No filler or redundancy; every word contributes to understanding.
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 simple nature (2 parameters, read-only), the description is adequate but could mention what the scan returns or how to interpret 'basic accessibility issues'. With no output schema and many related sibling tools, a brief note on output or use cases 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?
Schema description coverage is 100% (both parameters are described), so the baseline is 3. The description doesn't add parameter-level details beyond what the schema provides, but it doesn't need to since the schema is 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 (scan) and resource (Canvas course content) with the specific purpose (accessibility issues). It distinguishes from sibling tools like fix_accessibility_issues or fetch_ufixit_report by focusing on scanning for basic issues.
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 on when to use this tool versus alternatives like fetch_ufixit_report or parse_ufixit_violations. It doesn't mention prerequisites, output interpretation, or when not to use it. The description is purely declarative without situational 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?
The annotations already provide idempotentHint=true and destructiveHint=true, covering the safety profile. The description adds nothing beyond the bare 'update' — it does not clarify partial vs full updates, whether missing optional fields retain prior values, or any other behavioral nuances. Since annotations carry the burden, the description's minimal additional context yields a low-but-not-contradictory 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?
One concise sentence, no filler. It is front-loaded and effectively sized for the tool's simplicity. 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?
Given the tool's straightforward nature, the description plus rich schema and annotations are sufficient for basic use. However, it omits details like partial update semantics (whether unspecified fields are untouched) and error scenarios, which would be valuable for an update mutation. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'New module name'). The tool description itself does not add any param detail, but the schema fully documents meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing module's settings' — a specific verb and resource that distinguishes it from sibling tools like create_module and delete_module. No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for modifying an existing module, but offers no explicit guidance on when to choose this over create_module or delete_module, nor any prerequisites beyond the required parameters visible in the schema. It is adequate but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-idempotent and non-destructive behavior. The description adds no extra context about side effects, permissions, or rate limits, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the assignment operation for a simple use case. It does not mention potential side effects or preconditions, but given the annotations and lack of output schema, the information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters and already clarify reviewer vs. reviewee roles. The description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Manually assign a peer review') and specifies the target ('to a student for a specific assignment'), distinguishing it from other peer-review related tools that focus on listing, analyzing, or generating reports.
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 indication of when to use this tool versus automatic assignment alternatives or other peer-review tools. It only mentions 'manually' but does not clarify scenarios or prerequisites.
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 provide idempotentHint:false and destructiveHint:false, and the description adds scheduling context (auto-lock, delayed posting) beyond them. However, it does not mention who is notified, whether existing announcements are affected, or permission requirements.
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, 19-word description that front-loads the verb 'Create' and immediately defines the resource. The optional scheduling is captured in a compact clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a moderate parameter count and a rich input schema covering all definitions, the description is complete enough for a creation operation. No output schema expected for a void-ish create tool; schedule semantics could be improved with a note that announcements are posted immediately if no lock/delay is set.
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?
Input schema already covers all 5 parameters (title, message, course_identifier, lock_at, delayed_post_at) with per-parameter descriptions. The description adds a little clarity (e.g., 'ISO 8601 datetime', 'Canvas ID or code'), but most semantic weight is carried by the schema. No parameter-level caveats are given.
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?
Description uses a specific verb 'create' with a clear object 'announcement' and identifies the course context and optional scheduling. It does not explicitly distinguish itself from sibling tools that also create objects (e.g., create_discussion_topic).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear use case (creating an announcement) and mentions optional scheduling, but it provides no explicit when-not guidance, nor references to alternative tools such as update or delete, nor exclusions for quiz or assignment postings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply destructiveHint=true and idempotentHint=true. The description adds meaningful context beyond annotations by stating the deletion is permanent and that Canvas may retain a recycle-bin copy depending on admin settings. This does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded, and contains no redundant or filler content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter deletion tool with destructive and idempotent annotations, the description is mostly complete. It includes permanence and recycle-bin caveats, though it could better address the existence of sibling deletion tools and expected result behavior, but this is not critical for a basic delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully: announcement_id is 'Announcement ID to delete' and course_identifier is 'Course code or Canvas ID.' With 100% schema coverage, the description does not need to add parameter semantics, so a baseline of 3 is appropriate.
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 and resource: 'Delete an announcement from a Canvas course.' It identifies a single announcement, but it does not distinguish this tool from sibling deletion tools such as delete_announcement_with_confirmation, bulk_delete_announcements, or delete_announcements_by_criteria.
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 the sibling delete variants. The permanence warning implies caution but does not explain when confirmation-based, bulk, or criteria-based deletion should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true, and the description's 'Get' verb reinforces that this is a read-only operation. However, it does not add any additional behavioral context such as rate limits, permissions, or side effects beyond what the annotation provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the essential purpose without any redundant or unnecessary words. It is well-structured and front-loaded with the action and target.
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 (no parameters, no output schema), the description sufficiently conveys what the tool does. It could be slightly more explicit about what 'status and statistics' includes, but it is complete enough for a straightforward getter operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter information to add. According to the rubric, with 100% schema coverage (vacuously), a baseline score of 3 is appropriate, and the description does not need to clarify any 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 tool's function with a specific verb ('Get') and resource ('current data anonymization status and statistics'), making it distinct from sibling tools such as 'create_student_anonymization_map' and 'fetch_ufixit_report'.
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 lacks any guidance on when to use this tool versus others. It does not mention prerequisites, conditions, or alternative tools for similar tasks, leaving the agent to infer usage context solely from the name and purpose.
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?
Description matches readOnlyHint annotation (both indicate read operation). However, it doesn't disclose that auto_mark_read defaults to true, which is a behavioral trait beyond the annotation. Since annotation covers safety and output schema covers return, this is adequate but not enhanced.
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?
Single sentence, front-loaded with action and object, no redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read operation, the schema covers parameters, annotations cover safety, and output schema covers returns. The description is terse but sufficient; a 4 reflects the missing usage guidance but acknowledges the structured fields fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all three parameters with 100% coverage. Description adds nothing beyond confirming messages inclusion, which is already in the include_messages parameter. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'get' and resource 'conversation details', with 'with messages' clarifying the scope. Distinguishes from siblings like 'list_conversations' which lists, and 'send_conversation' which creates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. It doesn't mention that list_conversations should be used to find conversation IDs, or that mark_conversations_read handles read state. The description implies usage but lacks 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?
The annotation readOnlyHint=true already indicates this is a read-only operation, so the description doesn't need to repeat that. The description adds that it returns a 'comprehensive overview' including pages, modules, and syllabus, which is useful context. However, it doesn't disclose details like whether the response is aggregated or how the include flags affect the output structure, but given the annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose. It is front-loaded with the main action and resource, and every word earns its place. 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?
Given the tool's moderate complexity (4 parameters, all documented in schema) and the readOnlyHint annotation, the description is fairly complete. It doesn't need to explain return values since there is no output schema, but it could benefit from a note about the aggregated nature of the response. However, for a read-only overview tool with good schema coverage, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the concept of 'comprehensive overview' and mentions the content types, but it doesn't add meaning beyond the schema's parameter descriptions. The include_* flags are self-explanatory from the schema, so the description adds minimal value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a comprehensive overview of course content including pages, modules, and syllabus. It uses a specific verb ('get') and resource ('course content overview'), and the mention of specific content types distinguishes it from siblings like get_course_details and get_course_structure, though it doesn't explicitly differentiate from those.
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 an overview of course content, but it doesn't explicitly state when to use this tool versus alternatives like get_course_details, get_course_structure, or the individual get_syllabus, list_pages, list_modules tools. No exclusions or alternative recommendations 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?
The annotation readOnlyHint=true already signals this is a safe read operation, and the description does not contradict it. The description adds no extra behavioral context beyond 'detailed information,' which is vague but not misleading. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that front-loads the verb and resource. It contains no filler or redundant information, making it maximally concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only get-by-ID tool with two well-documented parameters and no output schema, the description adequately covers the essential context. The term 'detailed information' is somewhat vague, but given the tool's simplicity and the availability of sibling tools for broader views, it is sufficiently complete for an agent to select and invoke appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (topic_id and course_identifier), so the description adds no additional meaning. The phrase 'specific discussion topic' reinforces the need for an identifier but adds no new semantics beyond the schema. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('detailed information about a specific discussion topic'), making its purpose evident. It implicitly distinguishes from list_discussion_topics by focusing on a single topic, though it does not explicitly differentiate from get_discussion_entry_details or get_discussion_with_replies, which might overlap semantically.
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 a user needs details for a specific topic (given a topic_id), which is a natural use case. However, it provides no explicit guidance on when not to use it (e.g., for replies or full discussion threads) or alternatives like get_discussion_with_replies. This is adequate but not instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Submit grades' which implies a destructive write operation, consistent with the destructiveHint annotation. It adds no extra behavioral details (e.g., whether grades are overwritten or appended) beyond the annotation, so transparency is adequate but minimal for a tool with annotations present.
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 followed by two concise 'IMPORTANT' notes. It is well-structured and avoids verbosity, conveying the core purpose and key prerequisites efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes essential context: the need for criterion IDs (with an example), the requirement that the rubric be attached and configured for grading, and a pointer to get_rubric. It does not mention return value, but since no output schema is provided, this gap is acceptable for an action-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for all parameters (e.g., 'Course code or Canvas ID'), providing full coverage. The description adds no additional parameter-specific guidance, so it meets the baseline expected given the high schema description 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 'Submit grades using rubric criteria.' This specifies the action (submitting grades) and the method (using a rubric), making it distinct from other grading tools like bulk_grade_submissions that may not use rubrics.
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 does not explicitly indicate when to prefer this tool over alternatives. It mentions 'Use get_rubric to find criterion/rating IDs' for a related task, but does not contrast with other grading tools or provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description aligns with that. However, the description adds no additional behavioral context—such as whether listing affects read status, pagination behavior, or default filtering—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 clear sentence with no unnecessary words. It is concise and front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema with fully described parameters and an output schema, the brief description is largely sufficient. It could improve by mentioning the configurable scopes or differentiating from sibling tools, but the overall context from annotations and schema covers most needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters, so the baseline applies. The description adds no extra meaning or relationships beyond what the schema already documents, such as how scope interacts with the other filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') with a clear resource ('conversations') and scope ('for the current user'), making it distinct from siblings like get_conversation_details and mark_conversations_read.
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 get_conversation_details should be used for retrieving a single conversation, nor that this listing does not modify read state. Usage context is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read operation. The description adds that the result includes both groups and members, but it does not clarify pagination, empty groups, permissions, or whether all course groups are always 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?
One clear, front-loaded sentence with no filler. Every word contributes to defining the tool's action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with a single parameter, the description adequately conveys the returned content concept (groups and their members). It is slightly thin on output format details, but the simplicity of the tool and the readOnlyHint keep it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter `course_identifier` is already described as 'Course code or Canvas ID'. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('all groups and their members'), and the scope ('for a specific course'). It is specific enough to distinguish this tool from siblings like list_courses or get_course_structure.
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, nor any exclusions or prerequisites. The only context is 'for a specific course,' which is more scope than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation, and the description's 'List' verb is consistent with that, so there is no contradiction. However, the description adds little beyond the annotation—it doesn't address potential large result sets, pagination, or permission requirements. With the annotation covering the core safety profile, the description provides marginal extra context by emphasizing the course scoping.
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: 'List all rubrics in a specific course with optional detailed criteria.' Every word serves a purpose, with the action verb first and no redundancy. It is a model of efficiency, packing the core function, scoping, and optional behavior into 12 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, 2-parameter list operation with a clear name and a readOnlyHint annotation, the description is sufficient to inform an agent of the primary behavior. It correctly signals the required course_identifier and the optional include_criteria. A more verbose description of return values or error handling would be unnecessary given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: include_criteria is documented as 'Include detailed criteria and ratings (default: True)' and course_identifier as 'Course code or Canvas ID'. The description's phrase 'optional detailed criteria' and 'specific course' gently echo these parameters but add no new information beyond the schema. Per calibration, with high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'List' followed by the resource 'rubrics' scoped to 'a specific course', which directly maps to the required course_identifier parameter. It clearly differentiates collection-level behavior from singular sibling tools like get_rubric and get_rubric_assessment by emphasizing 'all rubrics'. The optional criteria phrase pre-empts the include_criteria parameter, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this tool over its sibling alternatives such as get_rubric (singular) or get_rubric_assessment. There are no when-to-use, when-not-to-use, or prerequisite statements. While the list semantics are implied, the description misses the opportunity to direct an agent to fetch a single rubric via get_rubric when only one is needed.
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 include idempotentHint: true and destructiveHint: true, but the description does not elaborate on these. For instance, it doesn't disclose that the tool might overwrite an existing file (destructive) or that it can be run multiple times safely (idempotent). The description does not contradict the annotations, but it also doesn't add context beyond what annotations already provide. With annotations present, the description adds minimal behavioral context, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's core function without any unnecessary words. It is front-loaded with the primary action (create) and resource (local CSV file), 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?
Given the tool's moderate complexity (one parameter, no output schema), the description is adequately complete. It specifies the output (local CSV file) and the mapping purpose. However, it could benefit from mentioning the file location or how the anonymous IDs are generated, but these are not strictly required for basic usage. The annotations provide some context, so a score of 4 is justified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with only one parameter, course_identifier, described as 'Course code or Canvas ID'. The description does not add additional parameter semantics, but the schema itself is sufficient. With 100% coverage, the baseline is 3; however, the schema provides clear meaning, and the parameter is straightforward, so a small credit for clarity in the schema yields a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a local CSV file mapping real student data to anonymous IDs for a course. It uses specific verbs and resources, distinguishing it from siblings like get_anonymization_status by focusing on creation of a mapping file. However, it doesn't explicitly contrast with other anonymization-related tools, though the verb 'create' and resource 'CSV file' make the purpose clear.
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 creating anonymization mappings for a course, but it does not specify when to use this tool versus alternatives like get_anonymization_status or other data export tools. It also doesn't provide context on prerequisites or after-effects. There is some guidance in the tool's name and description, but it's not explicit about 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?
The annotation readOnlyHint=true indicates the tool is read-only, and the description is consistent with that, describing a 'Get' operation. The description adds the context that the analytics are about 'student performance' on a specific assignment, which goes beyond the schema. However, it does not disclose details like whether it returns aggregate statistics or individual breakdowns, or if any special permissions are needed. Given the annotation covers the main behavioral trait (read-only), the description adds reasonable context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that efficiently communicates the purpose. It is front-loaded with the key verb and resource, and there is no wasted text. It accurately reflects the tool's function without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two clear parameters and a read-only annotation, but the description could be more complete. It doesn't describe what the output looks like (though no output schema is provided) or any specifics about the analytics (e.g., metrics included). Given the complexity is low and the schema covers the inputs, a 3 is reasonable, but there is room to add more detail about the return value or typical use cases. Sibling tools like 'get_student_analytics' might overlap, so more clarity would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters ('Canvas assignment ID' and 'Course code or Canvas ID'). The description adds minimal extra meaning beyond the schema, just implying that the parameters identify a specific assignment. Since the schema covers the parameters well, a baseline of 3 is appropriate. The description does not clarify the relationship between the parameters or any format specifics, but the schema already does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving detailed analytics about student performance for a specific assignment. The verb 'Get' with the specific resource 'assignment analytics' is clear, and it distinguishes from sibling tools like get_assignment_details, which likely focuses on assignment content rather than performance analytics. However, it could differentiate slightly more explicitly from 'get_student_analytics' or 'get_peer_review_completion_analytics' which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need performance analytics for an assignment) but does not explicitly mention when not to use it or alternatives. Sibling tools like 'list_submissions' or 'get_my_submission_status' might provide related info, but no explicit guidance is given. The description is minimal and does not clarify the distinction from other analytics tools, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the safe read-only nature. The description adds no extra behavioral context, such as permission requirements, return format, or any side effects. It is consistent with the annotation but adds minimal value beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Get', and contains no redundant or filler words. Every word earns its place, making it an ideal concise description for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with no output schema, the description is adequate but not thorough. It doesn't clarify what 'content' includes (e.g., HTML, text, metadata) or elaborate on how the front page is determined, which could lead to slight ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a clear description of 'course_identifier' (Course code or Canvas ID). The tool description itself adds no parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('front page content') with a clear scope ('for a course'). It distinguishes itself from sibling tools like 'get_page_content' by targeting the course's front page specifically, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (retrieve front page content) but provides no explicit guidance on when to use this tool versus alternatives like 'get_page_content' or 'get_course_details'. No mention of exclusions, prerequisites, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true covers the safety profile (safe read operation). The description adds one behavioral nuance: the discovery scan only queries assignments where the peer_reviews flag came back true, and an assignment with a missing/stale flag would be silently skipped. This is useful beyond the annotation. However, it doesn't disclose what 'needs to complete' means (overdue vs. pending), pagination, or return format, but annotations exist and the tool is simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a secondary sentence embedded in the parameter description. No waste; front-loaded. The second sentence is entirely within the parameter schema (part of the tool definition), so the core description is minimal and to the point.
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 is a simple read-only list with 0 required parameters, good annotations (readOnlyHint), full schema coverage, and no output schema needed, the description is adequately complete. It covers purpose, scope, and a critical behavioral caveat (silent skip). No gaps that would prevent correct agent use. Fewer than 3 paragraphs: the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters are described in the input schema). The assignment_identifier description adds meaning beyond the bare parameter name by explaining context: it bypasses the discovery scan and warns about the peer_reviews flag limitation. course_identifier's meaning is clear from its schema description. The description adds nothing beyond schema, but schema fully covers it, so baseline 3 applies. The extra context about the flag issue justifies a small bump.
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 and resource: 'Get peer reviews YOU need to complete.' It distinguishes itself from sibling tools like list_peer_reviews and get_peer_review_assignments by emphasizing the personal 'YOU need to complete' scope. However, it doesn't explicitly contrast with these siblings, so it's clear but not fully differentiated in the description text itself.
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 is short and doesn't provide specific when-to-use guidance or exclusions beyond 'you need to complete.' The parameter descriptions on assignment_identifier provide implementation detail (bypassing the discovery scan) but no explicit guidance on when to choose this tool over get_peer_review_followup_list or list_peer_reviews. There's no explicit 'when not to use' or alternative tool references in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the description earns no credit for the safe-read nature. The main addition, 'including attempts used,' adds minimal behavioral context. It doesn't explain what happens if no submission exists, whether the user must be enrolled, or any other behavior beyond the bare fact of fetching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the tool's purpose and a key differentiator ('including attempts used'). No word is wasted, and it is easy to scan and 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 simple read-only lookup with two well-described scalar parameters and no output schema, the description is mostly adequate. The main gap is whether it should mention what to do when the user has no submission or what the output shape looks like, but those are minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both assignment_id and course_identifier are documented. The description doesn't add extra meaning beyond the schema, but the baseline of 3 applies when schema fully covers parameters. It does not need to elaborate further for a simple two-parameter lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with the target resource ('your own submission for an assignment') and a key qualifier ('including attempts used'). This clearly identifies the scoped, per-user nature of the tool, distinguishing it from sibling tools such as 'get_my_submission_status' and 'list_submissions'.
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 'your own submission' explicitly conveys this is for the current user's own submission, not others' submissions or general assignment data. While it doesn't explicitly name alternatives like list_submissions, the context is clear enough for an agent to choose between this and broader listing 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?
The readOnlyHint annotation already indicates a read operation, and the description's 'Get' is consistent. However, it does not add behavioral context beyond that, such as permission requirements or the structure of returned data, which would be useful given the lack of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the tool's purpose. It contains no unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple getter, but it does not explain the return structure or any nuances like whether it returns scores for all criteria or an overall score. Since there is no output schema, this lack of detail leaves some gaps, though the purpose is sufficiently clear for a basic use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as each parameter has a description in the schema. The tool description does not add any extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get rubric assessment scores for a specific submission.' It uses a specific verb (get), resource (rubric assessment scores), and scope (specific submission), which distinguishes it from sibling tools like get_rubric (rubric definition) and grade_with_rubric (grading).
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 needing rubric scores for a specific submission but does not explicitly state when to use it versus alternatives like get_rubric or list_rubrics. No exclusions or alternatives are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint correctly signals a safe read, and the description does not contradict it, but it adds little behavioral detail beyond 'optional search'. There is no disclosure of pagination, result scope, or file metadata vs content.
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 states the resource and key capability without repetition 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?
For a simple read-only listing tool with fully documented schema and a readOnly annotation, the description is adequate. However, without an output schema, it could usefully mention what the returned file list contains or any size limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description's 'optional search' only echoes search_term and contributes no additional semantic 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?
Description clearly identifies the action ('List'), the resource ('files in a Canvas course'), and an optional behavior (search). This distinguishes it from file-content siblings like download_course_file, read_course_file, and upload_course_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 operation is implied by the verb 'List' but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives for retrieving or uploading files. The 'optional search' hints at the search_term parameter but does not define 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the core action, such as whether unread counts are updated or that conversations are not deleted. This is acceptable for a trivial operation but adds no value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It conveys the essential information without any filler, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and an output schema, the description is sufficient. It clearly states what the tool does, and the annotations cover safety and idempotency. No additional context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a clear description for the single parameter (conversation_ids). The tool description adds nothing beyond what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark') and resource ('conversations') with the qualifier 'multiple', which clearly distinguishes this from sibling tools like list_conversations or get_conversation_details. It explicitly states the action and scope, making it obvious what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any preconditions (e.g., obtaining conversation IDs first via list_conversations) or mention that it should be used to clear unread counts. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare idempotentHint=true and destructiveHint=true, which covers safety and mutation expectations. The description adds the precondition that the assignment must already exist, but it does not describe overwrite/null semantics, response behavior, or other operational details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler, repetition, or extraneous detail. Every word contributes to identifying the tool's purpose.
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 rich 15-parameter schema and clear annotations, the tool is reasonably invocable. However, with no output schema and no mention of partial-update behavior, null-field handling, or return value, the description alone is not fully complete for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented with meaningful descriptions. The tool description itself adds no parameter-level meaning, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the target ('an existing assignment'), and the scope ('in a course'). This distinguishes it from create_assignment, list_assignments, and get_assignment_details 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 word 'existing' implies the tool is for modifying already-created assignments rather than creating new ones, but it does not explicitly mention alternatives or state when this should be preferred over create_assignment. Some usage context is implied, not fully specified.
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?
The readOnlyHint annotation is present, and the description adds context by specifying the output as a human-readable summary, which is not covered by the annotation. It does not mention error handling or side effects beyond the read-only nature, but given the annotation, the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (8 words) that is front-loaded with the action verb 'Format'. It contains no unnecessary words and efficiently communicates 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?
For a simple formatting tool, the description is fairly complete. It specifies the input (parsed violations) and output (human-readable summary), and the schema covers the parameter type. It does not mention error handling or the exact output format, but these are minor and the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the parameter ('JSON string from parse_ufixit_violations'). The tool description refers to 'parsed violations' which is essentially the same information, adding no new meaning beyond what the schema already covers.
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 ('Format') and the object ('parsed violations') and the output ('human-readable summary'), which distinguishes it from sibling tools that fetch, create, or delete data. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies it should be used after parsing violations (since it takes parsed violations), but does not state that directly or mention any alternative or complementary 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?
Annotations include readOnlyHint=true, so no contradiction exists. The description adds limited behavioral detail, such as optional inclusion of replies and full content, but these are already present in the input schema. No additional context about pagination, errors, or permissions is provided, and with readOnly covered, the description adds minimal extra value.
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 redundant words. It directly states the action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward listing tool with full schema coverage and a readOnly annotation, the description is sufficient. It doesn't explain return format, but since no output schema exists, that isn't required. It could note that replies are only fetched when include_replies is true, but the schema already conveys this, so the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters clearly described (e.g., include_replies: 'Fetch replies for each entry'). The description merely echoes 'optional full content and replies' without adding new meaning, so it stays at the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'discussion entries (posts)' and explicitly scopes to 'a specific discussion topic'. This distinguishes it from sibling tools like list_discussion_topics (listing topics) and get_discussion_with_replies (fetching a full thread).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what it does but offers no explicit guidance on when to use it versus alternatives like get_discussion_with_replies. It implies usage for listing entries but does not exclude similar tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint annotation provides read-only attribute, and description 'list' is consistent with non-mutating role. Doesn't go beyond pub annotations: natural amplification info e.g. no mention of permissions, response shape or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One line, direct and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Three descriptive parameters, 100% schema note coverage, clear output types. The returned page/resource isn't specified in description, but readOnlyHint plus schema enough. Simple read-only operation with standard params and intention.
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 is 100% detailed, and the description is in agreement with the parameters. The description mentions include_content_details but the default, and this is a level from a 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?
Description uses precise action 'List items within a specific module, including pages'. Includes distinct resource 'module scope' and indicates content breadth. This differentiates from siblings by targeting module items (module_id/course_identifier) and outlines pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use context (when to list module items) is implied but not explicitly explained as a choice against sibling tools such as get_pages or list_course_items. Notes no exclusions/exceptions/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?
Annotations already declare readOnlyHint: true, so the tool is safe and non-destructive. The description adds no further behavioral context, but for a simple read-only list operation, that is acceptable. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that states the primary purpose with no fluff. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the annotation and schema cover the essentials. There is no output schema, but for a listing operation the description suffices. It could mention that the result includes module metadata and optionally items, but that is implied by the include_items parameter. It is adequately complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (course_identifier, search_term, include_items) are documented. The description adds nothing beyond the schema, but the baseline of 3 applies when the schema carries the full burden. It does not clarify that 'search_term' filters by name or that 'include_items' controls item summaries, but those are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (modules) with a scope (in a course). It distinguishes from siblings like list_module_items (which lists items within modules) and create_module/update_module/delete_module (which are mutations). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need a list of modules for a given course. It does not provide explicit guidance about when not to use it or mention alternatives like list_module_items for module contents. However, given the tool's simplicity and the presence of a clear parameter for course identification, the context is sufficient for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true covers the safety profile, and the description does not contradict it. However, the description adds no extra behavioral context beyond what the annotation provides, such as return format or side effects, but given the annotation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It is concise and immediately conveys the purpose and input source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only, no output schema). The description specifies the input source and outcome. While it does not detail the exact structure of extracted violations, for a parsing step this is acceptable given the low complexity and good 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 100%, with the parameter report_json described as 'JSON string from fetch_ufixit_report'. The tool description does not add additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: parsing UFIXIT report content to extract accessibility violations. It uses a specific verb (parse) and resource (UFIXIT report content), and it distinguishes itself from siblings like fetch_ufixit_report (which fetches) and format_accessibility_summary (which formats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the input comes from fetch_ufixit_report, which situates it in a pipeline, but it does not explicitly state when to use it versus alternatives or provide exclusions. The context is clear but not explicit about 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?
Annotations only specify idempotentHint and destructiveHint, both false. The description adds only a misuse warning, but does not disclose actual side effects (e.g., visibility, permanence, permission requirements) or post-execution behavior. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one sentence for the core action and one sentence for the critical warning. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action and an important caveat regarding announcements. It lacks a positive usage scenario but is adequate for a simple tool with no output schema and straightforward parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides clear descriptions for all three required parameters (course_identifier, topic_id, message), achieving 100% coverage. The description does not add additional parametric details, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Post a new top-level entry to a discussion topic.' This distinguishes it from reply_to_discussion_entry (which posts a reply) and create_discussion_topic (which creates a new topic).
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 an explicit exclusion: never use this tool to work around a failed announcement. While it doesn't contrast with all sibling tools, the phrase 'top-level entry' implies it's for starting new threads, and the warning clarifies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description is consistent. The description adds that it fetches a report from a course page, implying potential network access and page content retrieval, but does not contradict the annotation. It adds some value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence long, directly states the purpose, and contains no redundancy. It is optimally concise and 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?
The tool has a simple purpose, 2 params with full schema coverage, readOnly annotation, and no output schema. The description is adequate for the level of complexity, though it could mention what the report contains, but that is not essential given the clarity of the name and the presence of related tools for parsing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The description does not add extra semantics beyond the schema, but the schema already provides clear definitions including default for page_title. A score of 4 is given because the tool has only 2 params and the description aligns with the rich schema, but no extra value is added by the description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and resource 'UFIXIT accessibility report' from 'Canvas course pages', clearly distinguishing the tool's core function. It is not a tautology and implies a read operation, but it does not explicitly compare to siblings like parse_ufixit_violations or scan_course_content_accessibility, which may share the UFIXIT domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a report given a course identifier, but it does not specify when to prefer this tool over similar ones, nor any prerequisites or exclusions. The context is clear but the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint: true and idempotentHint: true. The description explains the dry_run default (preview only, apply with flag set to false) which directly addresses the destructive nature and adds safety context. It doesn't contradict annotations; it complements them. The description also clarifies the flow (scan first, then fix). Slight gap: doesn't explicitly say 'this permanently modifies course content' but dry_run explanation implies it.
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?
Description opens with a clear verb+resource sentence, then a compact 2-line workflow. No fluff. The two-step instruction (scan first) is front-loaded. Slightly redundant with schema's dry_run description, but overall 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?
Covers the key operational context: what it fixes, the prerequisite scan step, and the safety default. Given the schema covers all params and the tool has no output schema (not needed for an action tool), this is complete enough. It doesn't mention return values, but they're minimal for a fix operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with 100% description coverage-held, so baseline is 3. The description reinforces dry_run semantics but doesn't add syntax or deeper meaning beyond the schema. The fix_types list is in the schema enumeration, so minimal added value.
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?
Description clearly states it auto-fixes accessibility issues in Canvas course content, using a specific verb (
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Run scan_course_content_accessibility first to see what will be fixed', creating a clear sequential workflow and distinguishing this from the scanner sibling. However, it doesn't explicitly list contrast scenarios or say when NOT to use it (e.g., if manual editing is preferred, or if content is locked). Still, the prerequisite guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, so the agent knows this is a mutation with potential destructive effects. The description adds the useful boundary that content is not changed, but it does not disclose what makes it destructive (e.g., unpublishing a page, changing front page, altering editing roles). The schema carries some of this burden, but the description itself could add more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise, front-loaded sentence. Every word earns its place by clarifying both the action and the scope (existing page, no content change). No fluff or 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?
For a mutation tool with 6 parameters and no output schema, the description is somewhat sparse. It does not mention what the tool returns, potential failure modes, or the significance of the destructive hint. However, the rich schema and annotations partially compensate, making this an adequate but not complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific semantics beyond the schema, except implicitly clarifying that all parameters are settings-related (not content), which is a minor addition.
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 ('Update') and resource ('settings for an existing page') and explicitly clarifies what it does NOT do ('without changing content'). This clearly distinguishes it from sibling tools like edit_page_content and delete_page.
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 'without changing content' implies the tool is for settings-only updates, providing clear context for when to use it. However, it does not explicitly name alternatives or state when NOT to use it, so it's one step below explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotentHint=false and destructiveHint=false, letting the agent know repeated calls create new items and no data is deleted. The description adds the conditional parameter requirements but does not disclose additional behavioral traits such as validation outcomes or permissions. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action 'Add an item to a module,' followed by a single critical note on parameter requirements. Every sentence serves a distinct purpose and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description covers the key purpose and necessary conditional fields, leveraging the rich schema for param details. It doesn't mention error behavior or return values, but given schema coverage and sibling context, this is sufficient. A 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description's IMPORTANT note about content_id/page_url/title repeats the conditional requirements already present in the schema property descriptions, adding no new meaning beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' with a clear resource 'item to a module,' directly matching the tool's function. It is distinct from sibling tools like create_module, update_module_item, and delete_module_item, making the operation unambiguous. The additional required-fields note reinforces the add action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (adding items to modules) and provides operational guidance for required fields per item type. It doesn't explicitly state when not to use alternatives like update_module_item, but the operation name and verb 'Add' create a clear context with 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?
Annotations already declare readOnlyHint=true, so the description doesn't repeat that. It adds value by explaining the snapshot nature ('Each call reads progress once') and terminal results including migration issues when available. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste. The purpose is front-loaded in the first sentence, and the polling rule is stated compactly. No redundant or filler content.
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 output schema exists, the description covers the key behavioral aspects (polling and terminal results) well. However, the complete absence of parameter documentation makes it less complete than ideal for a 2-required-parameter tool with 0% schema coverage.
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 doesn't explain the two parameters (course_identifier, migration_id). While the tool name hints at what they mean, a new agent gets no explicit guidance on how to obtain or format these values, which is a significant gap at 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single content migration and its progress snapshot. The verb 'Read' and resource 'content migration' are specific, and it distinguishes itself from siblings like create_content_migration by focusing on status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit polling guidance: 'Call again only when poll_again is true', giving a clear condition for subsequent calls. It doesn't name alternatives, but the polling instruction is a strong usage signal that tells the agent when to call again.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds no extra behavioral details beyond stating it retrieves structure. No contradictions. It minimally extends the annotation context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero unnecessary words. It conveys the action, resource, and key advantage efficiently.
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 no output schema, the description could specify the return structure shape, but 'module and item structure' sufficiently sets expectations. The tool is simple with only two well-documented params and a read-only hint, making this description adequate for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, with detailed descriptions (e.g., course_identifier accepts code or Canvas ID, include_unpublished defaults to true). The description adds no additional parameter context beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get the full module and item structure for a course in a single call.' It specifies the resource (course structure) and distinguishes from siblings like list_modules and list_module_items by emphasizing the full nested structure and the single-call advantage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when you need the complete module and item hierarchy at once, contrasting with separate list calls. However, it does not explicitly state when not to use it or name alternatives, though the context of 'single call' hints at the trade-off.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description not needing to state safety is fine. The description adds the 'current' and 'across all courses' scope, which is useful context. However, it does not mention anything about the data freshness (e.g., real-time vs cached) or potential for empty results if not enrolled, which could be relevant given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that fully captures the tool's function. No wasted words, front-loaded with the action and scope. 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?
Given the tool has no parameters and no output schema, the description is sufficient to understand the tool's purpose and scope. It is complete for the tool's simplicity. Slight deduction because it doesn't clarify the format of grades (e.g., letter, percentage) or whether it includes past course grades, but this is minor given the straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (no properties). The description adds no parameter info because there are none. The baseline for zero params is 4, and the description correctly states the scope, which is the only relevant input context. No gaps here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the user's current grades across all enrolled courses. It uses a specific verb ('get'), clarifies scope ('across all enrolled courses'), and differentiates from siblings like 'get_my_upcoming_assignments' or 'get_my_submission_status'.
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 when the user wants grades for all courses, but does not explicitly state when not to use it or suggest alternatives. For example, it does not mention that 'get_course_details' might be more appropriate for single-course specifics, or that 'get_my_submission_status' is for assignment-level info. Slight gap in proactive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which covers the safety profile. The description adds the 'unread' filter context but does not disclose scope (e.g., current user, all conversations) or any other behavioral nuances. With annotations present, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, with no filler 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 simple, parameterless tool with an output schema present, the description is largely complete. It clearly states what the tool returns (a count of unread conversations). A minor gap is the lack of explicit scope (e.g., whose conversations), but the overall simplicity and output schema lower the burden.
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 0 parameters, so the baseline for parameter semantics is 4. The description does not need to explain parameter syntax, and the schema is trivially complete. No additional parameter information is possible or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get number of unread conversations' clearly uses a specific verb ('Get') and resource ('unread conversations'), and it distinguishes itself from sibling tools like list_conversations by returning a count rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a count of unread conversations, but it does not explicitly state when to prefer this over alternatives like list_conversations or mark_conversations_read. The context makes the use case fairly obvious, so this is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent already knows this is a safe read operation. The description adds useful scope information by clarifying that the search covers both registered MCP tools and the TypeScript code-execution API, but it does not disclose return format, pagination, or other behavioral details. With annotations covering the safety profile, 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 focused sentence that front-loads the action and resource, provides helpful parenthetical examples, and then clarifies the important second search category. Every part earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters, full schema description coverage, and a readOnlyHint annotation, the description is largely sufficient: it names the target, the two categories searched, and concrete examples. It does not explicitly describe the output shape, but the detail_level enum already communicates the names/signatures/full variants, so the missing return-format details are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters fully: query has a default and explanation ('empty = all'), and detail_level has an enum with per-value descriptions. The description adds no parameter-specific meaning beyond the general keyword-search concept, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and a clear resource ('available Canvas tools'), and it goes further by explicitly defining the scope as both registered MCP tools and the TypeScript code-execution API. This distinguishes it from all sibling tools, which operate on courses, assignments, discussions, and similar domain objects rather than on the tool catalog itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: this is the discovery/search tool for finding available tools by keyword, with concrete examples and a note that it also covers the TypeScript API. It does not explicitly name alternatives or say when not to use it, but no sibling tool offers a comparable search capability, so the intended use is well implied.
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 include destructiveHint: true, which the description does not contradict. The description adds that the file ID can be used downstream, but does not disclose potential side effects like overwriting existing files (on_duplicate parameter) or permission requirements. With annotations already flagging destructiveness, the description adds minimal extra behavioral context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a useful downstream usage note. No wasted words, and it is well-structured for quick parsing.
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 has 5 parameters, 100% schema coverage, and no output schema, the description is fairly complete. It explains the purpose, the return value usage, and the main parameters are covered by the schema. It could mention the on_duplicate behavior or folder_path default, but those are in the schema. The description is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds a note about the returned file ID usage, but does not add extra meaning to parameters beyond what the schema provides. Baseline 3 is correct since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a local file to Canvas course storage, with a specific verb ('Upload') and resource ('file to Canvas course storage'). It distinguishes from siblings like download_course_file and read_course_file by focusing on the upload action, and mentions the returned file ID can be used with add_module_item or send_conversation, which adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to upload a file to a course) and provides downstream usage examples (add_module_item, send_conversation). However, it does not explicitly state when not to use it or mention alternatives like upload to a different location, but the context is clear enough for an agent to decide.
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?
The annotations provide destructiveHint=true and idempotentHint=true, but the description adds crucial context: the deletion is permanent and Canvas may retain a recycle-bin copy depending on admin settings. This goes beyond the annotation and informs the agent about potential data recovery limitations, which is valuable for a destructive 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 extremely concise: two sentences that convey the core purpose and the most critical warning. No filler words, every piece of information is essential. It is front-loaded with the primary action and immediately follows with the irreversible consequence.
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 that the tool has a high schema coverage (100%), no output schema, but does have critical annotations (destructive, idempotent), the description covers the essential aspects. It does not describe behavior on partial errors (like stop_on_error) but that is covered in the schema. It is complete enough for an agent to decide to use it and understand the irreversible nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear descriptions for each parameter, including the purpose of 'limit' and 'dry_run' safety feature. The description adds minimal extra meaning beyond the schema, but it does highlight the dry_run safety in the limit description. Since the schema already thoroughly documents the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Delete multiple announcements from a Canvas course.' It specifies the resource (Canvas announcements) and the scope (multiple, not a single one), which directly distinguishes it from the sibling tool 'delete_announcement' (singular). The permanent nature is also highlighted, reinforcing the destructive purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates when to use this tool by naming 'multiple announcements' and contrasting with the singular 'delete_announcement' sibling. However, it does not explicitly mention when to prefer this over 'delete_announcement_with_confirmation' or 'delete_announcements_by_criteria', nor when not to use it (e.g., if a safe, rollbackable operation is needed). The 'permanent' warning implies a cautious usage, but lacks explicit 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?
Annotations already declare destructiveHint=true alerting the agent to mutating behavior.the description adds 'Settings only' scope, which helps avoid misuse. However, it doesn't explicitly warn that the update applies to ALL pages in the comma-separated list, nor does it mention any permission requirements or that changes are irreversible. With destructiveHint=true already provided, the description contributes some context but doesn't go beyond what annotations already signal.
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, first states the core purpose, second clarifies scope and redirects to the sibling tool. No filler. Every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk-update tool with 5 parameters and no output schema, the description covers the scope boundary well and the schema documents all parameters. It could mention that the update applies to all listed URLs at once or warn about overwriting existing settings, but the annotation destructiveHint already signals danger. Overall, it's sufficient for an agent to know when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — every parameter has a clear description in the schema (e.g., notify_of_update explains it's save-time only and not reflected in responses). The tool description adds the overall 'settings' framing and explicitly says it cannot rename or change content, which helps clarify what the settings params (published, editing_roles) are for. However, the description doesn't add syntax or value constraints beyond the schema, so it's at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update settings for multiple pages at once' which uses a specific verb (update) with a specific resource (page settings) and clear scope (multiple pages). It explicitly distinguishes from content editing by saying 'Settings only — this tool cannot rename pages or change page content,' which differentiates it from sibling tools like edit_page_content.
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 what the tool does NOT do ('cannot rename pages or change page content') and directs the agent to 'use edit_page_content to change a page's body.' This gives clear exclusion guidance and names the alternative tool for content changes. It implies the intended use case (bulk settings updates) without needing further elaboration.
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?
The annotation readOnlyHint: true declares it as a read-only operation, and the description's use of 'Get' aligns with that. No side effects are described, which is appropriate since it is read-only. The description does not add extra transparency beyond the annotation, but it does not contradict it either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no unnecessary words. It is front-loaded with the core functionality and immediately clear. The parameter description is also concise and to the point.
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 there is no output schema, the description does not explain what information the returned assignments will contain (e.g., due dates, course names, status). While the purpose is clear, the agent might not know if this tool provides the specific details needed for a given task. This leaves some room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'days' is well described as 'Number of days to look ahead (default: 7)', explaining both its meaning and default value. This fully covers the semantic meaning, allowing an agent to use it correctly without ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving upcoming assignments across all courses. It uses the verb 'Get' and specifies the scope ('across all courses'), making the purpose unambiguous. It is distinct from sibling tools like 'get_my_todo_items' or 'get_course_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 does not explicitly mention when to use this tool versus alternatives. It implies it is for all courses and personal assignments, but lacks explicit guidance on when not to use it or when to prefer another tool. This is a minor gap for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which aligns with the read operation described. The description adds value by specifying that the content is untruncated and that media is reported explicitly, offering behavioral details beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with exactly two sentences that efficiently convey the tool's purpose and notable output behavior without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations and schema are already rich (readOnlyHint, full param coverage), the description sufficiently covers the tool's core behavior. It doesn't describe return format details like pagination, but no output schema exists and the description covers the primary use, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions (100% coverage), so the description does not need to repeat them. It adds minimal additional meaning but the schema does the heavy lifting, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the full content body of a specific page, distinguishing it from related tools like get_page_details or list_pages by emphasizing the full, untruncated HTML body and explicit media inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving complete page content and explicitly mentions that it returns raw HTML and media inventory, which differentiates it from other page-related tools. It lacks explicit when-not-to-use or exact alternative references, but the context 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?
Annotations already flag destructiveHint and idempotentHint, but the description adds valuable context: it highlights that deletion is permanent, removes module associations, and explicitly states that underlying content is preserved. This goes beyond the annotation flags and clarifies the actual 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 extremely concise—two sentences, the first stating the action and the second delivering the critical caveat about content preservation. Every word carries weight, and the important warning is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the essential behavior: permanent deletion, impact on module associations, and non-deletion of underlying content. It provides enough information for an agent to use it correctly without over-explaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described ('Module ID to delete' and 'Course code or Canvas ID'). The description adds no extra meaning about parameters or their formats, so it meets the baseline but does not enhance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete a module from a course') and distinguishes from siblings like delete_module_item by explicitly clarifying that the module organization is removed but content is not. It also explains the scope of deletion (module and its item associations) precisely.
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 (to delete a module) and indirectly differentiates from delete_module_item by noting that content is not deleted. However, it does not explicitly mention alternatives like delete_module_item for removing individual items, missing a direct when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint is present, and the description describes a query that returns data without side effects. It does not add extra context like permissions or rate limits, but it is consistent with the annotation, so transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, direct, and includes essential details without redundancy. Every phrase adds value, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description provides enough context: it states the output is a ranked table with engagement score and mentions the use case. It does not detail every possible output field, but it covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the input schema, and the tool description clarifies that the include flags correspond to the engagement metrics. This provides clear meaning for each parameter, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves per-student engagement analytics, lists specific metrics (page views, participations, assignment counts), and mentions the endpoint and the output (ranked table with engagement score). This makes the purpose unambiguous and distinguishes it from other analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'useful for identifying disengaged students' but does not explicitly compare to other tools or state when not to use it. It lacks explicit alternative recommendations, so the usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint: true, covering the primary behavioral trait. The description adds context about returning untruncated content but does not mention any additional behaviors such as authentication, rate limits, or side effects. Since it adds only minimal insight beyond the annotation, a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of just two sentences. It front-loads the primary purpose in the first sentence and adds a clarifying contrast in the second. There is no redundant information or fluff, making it exceptionally well-structured.
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 simple nature of the tool and the rich schema descriptions, the description is complete. It states what the tool returns (full syllabus body) and clarifies how it differs from its sibling, providing sufficient context for an LLM to select and invoke it appropriately without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides comprehensive descriptions for all parameters (course_identifier, max_chars, output_format) with clear semantics and defaults. Since the schema coverage is 100%, the description need not repeat this information, but it also adds no extra parameter context, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the complete Canvas Syllabus tab content for a course, using the specific verb 'Get' and resource. It also distinguishes this from the sibling tool 'get_course_content_overview' by noting it returns full content rather than a preview, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with 'get_course_content_overview', indicating when to use this tool (when full syllabus content is needed) versus the alternative (when a preview suffices). This provides clear usage guidance without needing further elaboration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, and the description discloses the mutation: 'requests the migration.' It adds the short-lived token behavior and the preview step, which are critical behavioral traits. It also notes the date-shifting constraint ('accepts either all four date fields or none'), which is beyond what annotations provide. However, it doesn't fully explain what 'target-occupancy preview' contains or the token expiry 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?
Three sentences, all dense with useful information. The preview/confirm distinction is front-loaded, the token flow is explained, and the date-shifting rule is stated. No filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered elsewhere. The description explains the two-call sequence, the token, and the date-shifting constraint—all essential for correct invocation. It could be slightly more explicit about what happens if date fields are partially filled (it says 'either all four or none' which implies rejection), and it doesn't state prerequisites (e.g., user permissions), but given the complexity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description explains the purpose of confirmation_token (the short-lived token from the first call) and the date-shifting rule ('all four date fields or none'), which adds meaning beyond the schema's bare anyOf/null types. However, source_course_identifier and target_course_identifier are not explicitly distinguished in the description—though their names 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 two-phase action: 'Preview or confirm a full course-copy migration request.' It names the specific resource (course-copy migration) and the dual verb (preview/confirm), distinguishing it from sibling get_content_migration_status. It also explains the flow: first call returns a preview and token, second call with token confirms.
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 specifies when to make a second call: 'A second call with the token and identical arguments requests the migration.' It also hints at the preview-first pattern. It doesn't explicitly name alternatives beyond get_content_migration_status, but the two-phase flow is clearly described, which is sufficient guidance for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-idempotent and non-destructive. The description adds a caution about not using it for announcements, which helps prevent misuse, but does not detail permission requirements or side effects beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences covering purpose and a crucial warning. No unnecessary information or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's function and a key misuse case. Since no output schema is specified, return details are not required, and the warning adds practical 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 already provides clear descriptions for all parameters. The tool description does not add extra meaning or context beyond what the schema offers, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new discussion topic for a course. The description distinguishes it from announcement tools by warning against using it as a workaround, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a when-not scenario: never use it to post or work around a failed course announcement. It instructs to report the failure instead, giving clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true. The description adds crucial context by emphatically stating that content is NOT deleted, which is a non-obvious behavioral nuance beyond the annotations. It does not, however, mention idempotency (removing a non-existent item likely succeeds silently) or any permission requirements, but given the annotations cover the destructive nature, the added value is high. Score 4 because it goes beyond annotations but could add a bit more on idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place. The first states the primary action; the second provides a critical caveat. No fluff, no repetition. Perfectly concise and 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 mutation tool with three well-documented parameters and supportive annotations, the description is nearly complete. It would be slightly improved by mentioning idempotent behavior (e.g., removing an already-unlinked item is a no-op) and any side effects like reordering, but these are minor. The key behavioral warning is present. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all three parameters. The description adds no extra information about the parameters beyond what is in the schema. Baseline 3 is appropriate as the schema fully documents the 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 ('Remove an item from a module') and the specific resource (module item), and it distinguishes itself from siblings like delete_module (deletes an entire module) and add_module_item (adds an item). The scope is unambiguously defined.
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 provides usage context by clarifying that this tool only unlinks the item from the module, not deleting the underlying content. This helps an agent decide when to use this tool versus a destructive delete that removes content. It implicitly warns against using this when actual content deletion is desired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds context that the tool returns the user's role per course. No contradiction. Although it doesn't mention pagination or error scenarios, the read-only nature is clear and annotations lower the burden. The extra detail about roles adds value.
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 followed by concise usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description indicates what is returned (courses with roles) and provides essential usage context. It doesn't detail output fields or pagination, but given the read-only annotation and simple schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (include_concluded) and the schema provides full coverage (100%) with a clear description. The tool description does not add further parameter details, but the schema already explains the default and behavior, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('courses YOU are enrolled in') plus the extra scope of 'with your role in each.' It clearly distinguishes from the sibling tool check_enrollment, which reads the roster for others.
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 instead of check_enrollment for own-enrollment queries, and explains why check_enrollment is unsuitable (requires admin rights). This is explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds behavioral context about parameter precedence (uses rubric_id if both provided), which is useful beyond the annotation. It does not describe error conditions or return format, but given the annotation coverage, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by the key parameter rule. Every word contributes value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with no output schema, the description conveys the essential return content (criteria, ratings, points) and the parameter selection logic. It does not mention error cases or additional return metadata, but given the tool's simplicity and existing annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents each parameter (100% coverage), so the baseline is 3. The description adds meaningful detail about the relationship between rubric_id and assignment_id (at least one required, and precedence if both), which is not in the schema. This additional guidance surpasses the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches detailed rubric criteria, ratings, and points, which distinguishes it from list_rubrics (listing) and get_rubric_assessment (assessments). It also specifies the resource (rubric) and the two lookup methods, 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 explains when to use rubric_id vs assignment_id and the precedence rule. However, it does not explicitly contrast with sibling tools like list_rubrics or get_rubric_assessment, leaving the choice of tool somewhat implicit. It provides clear parameter usage context but 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?
Annotations provide readOnlyHint, but the description adds that announcements are excluded by default and can be included via the flag. This clarifies behavioral scope beyond what annotations convey, though no deeper behavior (e.g., pagination) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a parenthetical; every clause adds value. No fluff, front-loaded with the 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 is a simple list operation with readOnly annotation and schema covers parameters, the description is sufficient. It clarifies the announcement exclusion and directs to sibling tool, making it complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully documented in the schema. The description adds a brief explanation of include_announcements behavior (labeled entries), which slightly enhances understanding, but mostly relies on schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'discussion topics' with course scoping, and explicitly distinguishes from list_announcements, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for discussion topics) and when not (for announcements), and directs to list_announcements as an alternative. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint: false and destructiveHint: true. The description adds value by noting the bracket-notation form-data encoding and detailing the criteria JSON structure, which goes beyond the annotations. However, it does not elaborate on additional side effects, permissions, or rate limits, though the encoding and structure are useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear first sentence stating purpose, a technical note about encoding, a structured breakdown of the criteria parameter, and a concrete example. It is front-loaded and every section serves a purpose, with no redundant content despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the tool's purpose and the complex criteria parameter with an example, plus a crucial encoding note. It does not mention return values, but there is no output schema, and for a creation tool this is typically not critical. Overall, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description significantly enhances parameter semantics, especially for 'criteria', by specifying its JSON structure, required fields (description, points), optional fields (long_description, ratings), and an example. This goes well beyond the schema's one-line description and is essential 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 clearly states the tool's purpose: 'Create a new rubric in a course, optionally associating it with an assignment.' This is specific with a verb (create), resource (rubric), and scope (in a course). It distinguishes from siblings like list_rubrics, get_rubric, and associate_rubric by focusing on creation.
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 usage by explaining the tool creates a rubric and optionally links it to an assignment, along with a detailed breakdown of the criteria parameter and an example. However, it does not explicitly contrast with alternatives like create_rubric_from_csv or associate_rubric, nor does it state when not to use it, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals the operation is safe. The description adds valuable context by specifying that only the caller's own record is returned, not anyone else's, and enumerates the returned fields (user ID, name, login ID). This goes beyond the annotation and clarifies the tool's behavioral scope.
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 sentences that front-load the action and result, followed by the use case and scope. Every word adds value, with no redundancy or fluff. This is a model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no inputs, no output schema, read-only), the description is fully complete. It states the returned data, the privacy boundary, and the intended use case. There are no gaps left for the agent to infer, making it sufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema coverage is 100% (empty properties). The baseline score for 0 params is 4, and the description appropriately focuses on the output and use case rather than param details, which are nonexistent. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the caller's own Canvas identity (user ID, name, login ID). The verb 'Get' and resource 'my profile' are specific and distinct from all sibling tools, which focus on courses, assignments, or messages. It unambiguously answers 'who am I?'.
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 when to use it: 'useful when a tool needs your Canvas user ID or NetID.' It also clarifies scope ('Reports only your own record'), which prevents misuse for fetching others. Though it doesn't name alternative tools, this is unnecessary given no sibling offers similar functionality, so the guidance 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?
The description adds context beyond the readOnlyHint annotation by clarifying that the tool returns only announcements and excludes ordinary discussion topics. It does not contradict the annotation, and for a simple list operation, it provides sufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, precise sentences deliver all necessary information with zero waste. It is front-loaded with the action and scope, making it easy to scan.
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?
With one simple parameter, a clear return scope, and an explicit alternative, the description is fully sufficient for an agent to use the tool correctly without any output schema. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'course_identifier', is fully described in the input schema (100% coverage) as 'Course code or Canvas ID'. The description does not add extra meaning, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('a course's announcements'), and explicitly limits the scope with 'and nothing else.' It also distinguishes itself from the sibling tool 'list_discussion_topics' by noting that ordinary discussion topics are excluded, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Returns announcements only') and provides a direct alternative: 'Use list_discussion_topics for discussions.' This gives the agent clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently states that content is returned as base64 and explains the rationale for using this over downloading to the server. However, it does not mention potential limitations like file size errors or missing files, though the readOnlyHint annotation covers the read-only nature. The absence of explicit error handling or edge cases makes it slightly less transparent, but still adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three clear sentences. It avoids unnecessary fluff and effectively communicates the core functionality, usage context, and how to locate file IDs. The structure is logical and easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides complete context for a read operation: what it does, when to use it, how to find required inputs, and how it differs from the alternative. Given the simplicity of the tool and the absence of an output schema, this is sufficient and does not leave critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add extra meaning to the parameters beyond what is already provided in the input schema. Since schema coverage is 100% (all parameters have descriptive comments), the baseline score of 3 applies. The description's mention of file IDs indirectly references parameters but adds no new semantic 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 tool reads a file from a Canvas course and returns its content as base64. It explicitly distinguishes itself from download_course_file, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (when direct content is needed, especially across different machines) and when to avoid the alternative (download_course_file). It also provides guidance on how to find file IDs via list_course_files or list_module_items, giving clear usage directions.
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?
Beyond the annotations (idempotentHint false, destructiveHint false), the description discloses the two-step side-effectual behavior, the token invalidation if analytics shift, and that it sends urgent vs gentle reminders. This adds essential context for an agent to understand the non-idempotent nature and the safety of the preview call.
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?
Four sentences, purpose-first, with no filler. Every sentence contributes: purpose, design, invocation steps, and token caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-step workflow tool, the description fully explains the invocation sequence, the two modes, and the safety condition. The output schema covers return values, so no further description needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantics for confirmation_token: it comes from the preview call, is omitted to preview, and becomes void if analytics shifted. This contextualizes the parameters within the workflow.
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 'analyze peer reviews and send targeted reminders' and highlights the two-step workflow, distinguishing it from sibling tools like send_peer_review_reminders by explicitly explaining the preview-then-send design.
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 explains when to use it: call without confirmation_token for preview, show to educator, call again with token to send. It doesn't name alternatives but provides explicit step-by-step usage, making it clear when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate not idempotent and not destructive. The description adds crucial behavior: two-step design, token expiration, single-use, and invalidation on argument changes. This goes well beyond the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise paragraphs; the first sentence states the purpose, and the second details the necessary two-step process. No fluff, 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?
Given the tool's complexity, the description explains the core two-step behavior and token constraints. Output schema exists so return details aren't needed. It doesn't cover mode or context_code behavior, but schema covers those, so it is sufficiently complete for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 7 parameters, so baseline is 3. The description adds semantic context by explaining how confirmation_token is used in the two-step flow and that arguments must be identical, which enriches the schema's simple 'Token from the preview call; omit to preview'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Send customized messages to multiple recipients using templates.' This clearly distinguishes it from sibling messaging tools like send_conversation (single conversation) and send_peer_review_reminders (targeted reminders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the two-step preview/send flow with clear instructions: call without confirmation_token for preview, then with token and identical arguments to send. However, it does not explicitly compare to alternative sending tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotentHint=false, destructiveHint=false), the description discloses the token lifecycle: it expires, is single-use, and becomes void if any argument changes. It also explains that a preview must be shown to the educator, adding significant context about expected 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 compact and front-loaded: the first sentence states the core purpose, and the two-step flow is explained in a structured, readable block. There are no unnecessary sentences 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?
Given the complexity of 11 parameters and a multi-step flow, the description covers the most critical behavioral nuance (the preview/confirm mechanism). An output schema exists, so not describing return values is acceptable. It could mention permission prerequisites, but the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 11 parameters (100% coverage). The description adds key semantics for confirmation_token—it is required for the second step of a multi-recipient send and all other arguments must be identical to the preview. This extra context goes beyond the schema, but not all parameters are addressed.
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 clear verb+resource: 'Send messages to students via Canvas conversations.' It clearly states what the tool does and is specific enough to distinguish from siblings like list_conversations or send_bulk_messages_from_list by identifying the conversation channel.
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 explains the single-recipient vs. multi-recipient workflows, including the two-step preview-confirmation process. However, it does not mention alternative tools (e.g., send_bulk_messages_from_list) or when NOT to use this tool, which prevents a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits beyond the annotations: it explains the two-step preview/send mechanism, the need for identical arguments, and that it uses ordinary Canvas conversation messages rather than the native peer-review reminder action. This significantly helps the agent understand side effects and flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no wasted words. The first states purpose, the second removes a likely misunderstanding, and the third explains the workflow. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full parameter schema, annotations, and presence of an output schema, the description sufficiently covers the tool's operation and the important two-step flow. It does not explicitly discuss alternatives among sibling send tools, but that is not critical for this tool's basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters at 100% coverage, so the baseline is 3. The description adds extra meaning by explaining the confirmation_token workflow and emphasizing that the send call requires identical arguments to the preview call, which goes beyond the 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?
Clearly states 'Send direct Canvas Inbox messages about incomplete peer reviews,' identifying the exact verb and resource. It also distinguishes itself from Canvas's native peer-review reminder action and sibling send tools by specifying that it sends ordinary conversation messages.
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 workflow: call without a token to preview, show that preview to the educator, then call again with the token and identical arguments to send. It does not explicitly compare against sibling send tools, but the two-step protocol gives clear when and how guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description aligns with that by framing the operation as a download (side-effect is writing locally, not modifying Canvas). It adds valuable behavioral context by specifying the local-server constraint and the default save directory behavior. However, it does not mention potential file overwrite behavior or permission requirements, which are minor gaps given the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: stating the action, noting the environment restriction and alternative, and providing a lookup hint. There is no redundancy or filler. It is concise and front-loaded, making it easy for an agent to quickly 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.
Completeness5/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, no output schema, and a read-only annotation, the description is remarkably complete. It covers the core action, the operational context (local server), an alternative (read_course_file), and a lookup method for the file_id. This is enough for an agent to successfully invoke the tool without additional guidance, especially since the schema already documents parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully documented in the input schema (100% coverage), so the description itself doesn't need to repeat them. It adds value by advising how to find the file_id ('Use list_course_files or list_module_items to find file IDs'), which is a practical hint beyond the schema. The course_identifier and save_directory are adequately covered by schema descriptions, so the description enhances but does not duplicate param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Download a file from a Canvas course to the local filesystem.' It uses a specific verb (download) and identifies the resource (course file) and destination (local filesystem). It also distinguishes itself from read_course_file, which returns content in the response, making the tool's unique role clear among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: it notes that the tool is only available on a local (stdio) server, suggests using read_course_file for content-in-response scenarios, and instructs to use list_course_files or list_module_items to find file IDs. This covers when to use, when not to use, and how to prepare inputs, going beyond typical tool descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the 500-character cap, that the preview drops all markup, and — critically — that embedded media is listed separately rather than silently disappearing. These edge-case disclosures add real behavioral context that the annotation does not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with front-loaded purpose. The first sentence states the main action, and the second paragraph adds only high-value details: returns, the 500-character cap, markup-stripping, media handling, and the alternative tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values and does so thoroughly — it enumerates the metadata fields (status, timestamps, editor, editing roles), describes the preview format and cap, and handles the media edge case. For a two-parameter tool with a readOnly annotation, this is fully self-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 coverage is 100%, with both page_url_or_id ("Page URL slug or page ID") and course_identifier ("Course code or Canvas ID") fully documented. The description adds no meaningful parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence "Get a specific page's metadata plus a short text preview" uses a specific verb and resource, and "specific page" distinguishes it from list_pages. The closing sentence explicitly names get_page_content as the alternative for full content, further differentiating it from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (when metadata plus a plain-text preview is needed) and when not to: "For the full body, including media markup, use get_page_content." This is a clear, named alternative with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral details beyond annotations: it polls the import job, imported rubrics go to Draft state and are not returned by list_rubrics, and succeeded_with_errors is terminal and may mean zero rubrics. This adds substantial value not captured in the simple annotations (idempotentHint false, destructiveHint false).
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 well-structured with a clear overview, format specification, and bullet-pointed caveats. Each sentence earns its place, covering essential information without padding.
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 complexity (CSV parsing, async job polling) and the lack of an output schema, the description covers all crucial aspects: parameters, required format, and two non-obvious behaviors that could lead to false conclusions. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already describes both parameters, the description goes far beyond by specifying the exact CSV structure, required columns, an example, and validation notes. This fully compensates for any potential ambiguity in the schema and adds actionable 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?
Clearly states it creates one or more rubrics from a CSV string, distinguishing itself from the sibling create_rubric (which likely handles single rubrics). The verb 'create' and resource 'rubrics' are specified, and the CSV method differentiates it from alternatives.
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 strong context for when to use this tool (CSV-based bulk import) and explains required format and Canvas behaviors. However, it does not explicitly contrast with alternatives like create_rubric, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description builds on that by disclosing that it returns only yes/no plus minimal metadata, never roster, names, or grades. It further explains the indeterminate answer scenario, role scoping, and identifier matching rules—all beyond what annotations state.
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 thorough yet efficient. Each sentence adds critical information (purpose, scope, permissions, role semantics, identifier matching, and alternatives). It is well-structured with clear paragraphs and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, read-only query with special semantics), the description covers all necessary context: the indeterminate answer, role scoping, identifier matching, and permission requirements. It also mentions the output nature (yes/no plus minimal metadata) despite no output schema, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema: it explains how net_id is matched (login_id then sis_user_id, equivalence of formats), clarifies course_identifier forms, and details the role default and 'any' behavior. This raises it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether an external person's campus login ID is enrolled in a course, which is a specific verb+resource. It explicitly differentiates itself from sibling tools like get_my_enrollments (for the caller) and other getters. The scope (external person, not caller) and the exact nature of the answer (yes/no + minimal metadata) 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (roster-membership question about an external person) and explicit when-not-to-use alternatives (use get_my_enrollments for self). It also explains the role default and the 'any' option, and the permission requirement (roster-admin rights) with the consequence (INDETERMINATE answer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vishalsachdev/canvas-mcp'

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