Canvas LMS MCP Server

Server Quality Checklist

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

Latest release: v1.18.4
Disambiguation3/5
Most tools are scoped to a distinct resource-action pair, and the descriptions generally help disambiguate close cases like list_calendar_events vs get_upcoming_events. However, there are several near-overlapping families (view_course_structure/get_course_structure, view_account_notifications/list_account_notifications, grade-reporting and analytics tools, needs-attention triage tools) that require careful reading to select correctly.
Naming Consistency4/5
The overwhelming majority of tools follow a consistent snake_case verb_noun pattern: list_courses, get_course, create_assignment, update_page, delete_discussion, etc. Minor deviations like health_check, next_appointment, and view_*/get_* duplicates keep this from being a perfect 5, but the convention is still highly predictable overall.
Tool Count1/5
163 tools is far beyond a well-scoped MCP server surface and will overwhelm model context windows. Even for the broad Canvas domain, this suggests endpoint-by-endpoint tool creation rather than deliberate aggregation into coherent parameterized actions; separating into course-management, quiz-management, account-admin, and analytics servers would be far more usable.
Completeness3/5
The tool set provides deep read/write coverage for courses, assignments, pages, discussions, files, exports, outcomes, rubrics, appointments, and accommodations. However, there are notable lifecycle gaps: classic quizzes cannot be created/updated/deleted despite create_new_quiz referencing create_quiz, modules cannot be deleted after creation, module items have no update/delete path, and announcements have no create/update/delete surface.
Average 4/5 across 139 of 163 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 115 commits in the last 12 weeks
- Last stable release on August 15, 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.
Tools from this server were used 24 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Create a new assignment,' implying an additive, non-destructive operation, but annotations mark destructiveHint: true. This is a direct contradiction: creating a new assignment should not be flagged as destructive. The description also adds no behavioral context beyond the raw action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words and the core purpose is front-loaded. It is concise, though it sacrifices useful context that could have been included without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema is complete and no output schema is required, the description lacks necessary context about behavior, return values, and the conflicting destructive annotation. For a mutation/create tool, the description should at least clarify whether it overwrites, publishes, or interacts with existing course data; it does none of this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters, including required fields course_id and name. The description adds no parameter-level meaning beyond the schema, which is the expected baseline at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a new assignment in a course.' It clearly distinguishes this tool from siblings like create_new_quiz, create_course, and update_assignment by naming the assignment resource and the course 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 gives no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The intended use is only implied by the word 'create' and the resource name, with no comparison to related assignment tools like update_assignment or create_new_quiz.
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 (openWorldHint, destructiveHint). It does not mention that updates may overwrite fields, require permissions, or have non-obvious side effects. Given the destructive hint, the agent knows it's destructive, but the description itself contributes nothing.
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 filler or redundancy. It is efficiently front-loaded and fulfills its minimal purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter mutation tool with a destructive hint and no output schema, the description is too sparse. It lacks context about update behavior (e.g., partial updates, required permissions, how missing fields are handled) and does not compensate for the absence of usage guidelines. The schema covers parameter details but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a descriptive label. The description itself does not add any meaning beyond the schema, so it meets the baseline for high coverage but does not enhance 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 updates an existing discussion topic, distinguishing it from create_discussion or delete_discussion. However, it does not enumerate which fields can be updated, relying on the schema for that detail, so it is clear but not fully 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?
No guidance is provided on when to use this tool versus alternatives like create_discussion or delete_discussion. The description only states the action without indicating any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and openWorldHint=true, and the description adds no extra behavioral context. It does not mention what gets overwritten, whether changes are reversible, what permissions are needed, or any side effects beyond the generic 'update' wording.
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 words. It is front-loaded and easy to parse, though the brevity means it carries very little information beyond the title.
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 6 parameters, no output schema, and only a one-line description. It does not explain that course_id and page_url are required identifiers, which fields are optional, or that an update may overwrite existing content. This is insufficiently complete for a 6-parameter 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?
The input schema covers all parameters with descriptions and the schema description coverage is 100%, so the baseline is 3. The description adds no supplementary parameter meaning, but it does not need to compensate because the schema already documents each 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 says 'Update an existing wiki page,' which clearly identifies the verb (update) and resource (wiki page). It is distinct from create_page/delete_page via the mention of 'existing,' but it doesn't specify what kinds of updates are supported or how pages are identified, so it lacks full differentiation.
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 over alternatives like create_page or delete_page. 'Existing' only weakly implies the page must already exist, but the description does not explain use cases, prerequisites, or why to choose this over the sibling tools.
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' which is additive, but annotations declare destructiveHint: true, suggesting the tool may have destructive effects. This is a direct contradiction. The description adds no further behavioral context beyond this conflict.
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 sentence, front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters fully, the description lacks any context about side effects or return behavior, and the destructiveHint contradiction creates confusion. For a simple create operation, a one-liner could suffice, but the annotation conflict makes it incomplete.
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 6 parameters have descriptions in the schema, so the description does not need to compensate. The description adds no additional parameter semantics beyond the schema's full 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 (create), the resource (calendar event), and the platform (Canvas). It distinguishes from sibling tools like update_calendar_event and list_calendar_events by specifying 'new'.
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 update_calendar_event or list_calendar_events, nor any exclusions or prerequisites.
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 directly contradicts the annotations: annotations declare destructiveHint=true, but the action is creating a discussion, which is not destructive. Additionally, the description adds no behavioral context beyond the basic creation action, such as side effects, permissions, or response behavior. The openWorldHint is also not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence with no unnecessary words. It delivers the core purpose immediately without any fluff, making it optimally concise.
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 8 parameters, including nuanced options like is_announcement and delayed_post_at, and no output schema, the description is insufficient. It does not mention that the tool can create announcements or schedule posts, nor does it explain any return values or side effects. This lack of context could lead to misuse or confusion about capabilities.
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 description adds no additional parameter information. The baseline of 3 applies because all parameters are already documented in the schema, but the description does not enrich understanding of optional parameters like is_announcement, delayed_post_at, or discussion_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (a new discussion topic), and the scope (in a course). It unambiguously distinguishes from sibling tools like update_discussion, delete_discussion, list_discussions, and get_discussion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_discussion or list_discussions. It does not mention prerequisites, such as having appropriate permissions or whether it should be used only for new topics. The absence of any context or exclusions leaves the agent without direction.
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 is minimal and does not disclose side effects or potential destructive nature. The annotation 'destructiveHint: true' contradicts the create operation, creating confusion. The description adds no additional behavioral transparency beyond the contradictory 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, concise sentence with no redundant information. It perfectly fits the purpose 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?
Given the simplicity of a create operation, the description is adequate but lacks mention of return values or error behavior. Additionally, the contradictory annotation reduces the overall completeness, as the description does not resolve the ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are documented in the schema with brief descriptions, achieving 100% coverage. The description itself adds no extra nuance or clarification beyond the schema, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create a new module) and the resource (module in a course). It is distinct from other create tools like create_course or create_assignment based on the verb and resource, though it doesn't explicitly compare to siblings.
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 any prerequisites or context for calling it. The use case is implied by the tool name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, which are consistent with the description's read-only nature. The description does not contradict the annotations, but it provides no additional behavioral details (e.g., what 'missing submissions' means, whether it returns assignments from all courses).
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 key verb and resource. It is efficient and easy to parse, though it could benefit from a brief note on scope.
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 lack of parameters and output schema, the description is adequate for a simple read-only tool. However, it lacks context on what constitutes 'missing submissions' (e.g., no submissions vs. ungraded) and how results are scoped (e.g., all courses vs. current course).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully documented (100% coverage). The description adequately covers the only implicit parameter (the current user), so no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/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 assignments with missing submissions for the current user. It is specific and distinguishable from sibling tools like list_submissions or get_todo_items, though it could be more explicit about the context (e.g., within a course).
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 others. There is no mention of alternatives or exclusions, leaving the agent to infer its scope from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations provide openWorldHint and destructiveHint, the description does not add any behavioral context beyond the obvious creation action. It fails to mention that certain types require content_id, that adding items may affect module ordering, or any error conditions. With annotations present, the description's value is minimal, and it does not deepen the agent's understanding of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that lists the item types. It is efficient and front-loaded, but slightly terse; a bit more detail on usage or parameter dependencies could enhance clarity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 8 item types), the description is overly minimal. It does not explain the relationship between type and content_id/external_url, nor does it address potential conflicts or prerequisites. The schema covers parameter details, but the description lacks sufficient context for an agent to confidently select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the descriptions in the schema already document all parameters. The tool description does not add any additional meaning or clarify relationships (e.g., content_id is required for specific types) beyond what the schema provides. This is the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add) and the resource (item to a module), and lists the allowed item types, which distinguishes it from create_module (which creates a module itself). The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (adding items to existing modules) but provides no explicit guidance on when to use this tool versus alternatives like create_assignment or create_page. There is no mention of when not to use it or prerequisites, leaving the agent to infer based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate read-only and open-world hints, and the description does not contradict them. However, it does not add any additional behavioral context such as side effects, error handling, or any constraints beyond listing report types.
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, making it highly concise and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality but lacks details about the output format or any specific behavior. Given the simplicity of the tool and absence of output schema, it is adequate but 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 input schema already describes the account_id parameter with a description, so the tool description adds no extra meaning. The description only mentions 'a Canvas account' which is consistent but not additional.
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 lists available report types for a Canvas account, which is specific and distinguishable from other tools like list_accounts or get_account.
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, lacking any context about use cases, prerequisites, or conditions. It only states the action without explaining when it is appropriate.
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 and openWorldHint=true, so the description does not need to restate safety. However, the description's claim that the result 'including its time slots and participant counts' contradicts the schema where these are only included via the optional 'include' parameter. This misstatement misleads about default behavior, a notable gap given no additional behavioral details are 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, front-loaded sentence that states the action, object, and key details without any filler words. Every word earns its place, and it is appropriately concise for a simple get-by-ID operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and strong schema coverage, the description is mostly sufficient, but the misleading 'including' statement omits the optional nature of the include parameter. There is no output schema, so a clearer indication of what the base response contains (absent include) would improve completeness. It also does not mention any prerequisites or error conditions, leaving some context 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 schema already has 100% parameter coverage with clear descriptions for both 'include' and 'appointment_group_id'. The description adds minimal value beyond referencing 'time slots and participant counts', which are covered by the enum values. It does not clarify that these are optional or default behavior, so it neither enhances nor detracts significantly from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a single appointment group by ID, explicitly distinguishing it from listing all groups. The phrase 'including its time slots and participant counts' slightly misleads by implying these are always returned, but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies use for retrieving a specific group, but there is no explicit guidance on when to use this versus sibling tools like list_appointment_groups or create/update/delete. No alternatives or exclusions are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and scope of the operation. The description adds no behavioral details beyond 'listing', such as pagination, ordering, or the type of files (e.g., only top-level files or recursive). With annotations covering the basic safety profile, the description is adequate but adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'List all files in a course.', with no filler or redundant phrasing. It is front-loaded and directly communicates the tool's purpose. Every word serves a 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?
The tool is simple with one parameter and full schema coverage, and annotations provide basic safety context. However, the description does not clarify what 'files' means in this context (e.g., course files vs. uploaded files), nor does it mention any output structure or potential limitations. It is minimally acceptable but could be improved by specifying the file scope or linking to related 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?
The schema description covers 100% of parameters (course_id), and the description itself does not add any additional parameter semantics. Since the schema already explains the parameter, the description adds no value here, resulting in the baseline score of 3.
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 (files in a course), using a specific verb+resource pattern. It distinguishes from many sibling tools by specifying 'all files' and 'in a course', but it does not differentiate from other file-related tools like list_folders or list_course_submission_files, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, preconditions, or alternative tools, such as list_folders for folder structures or list_course_submission_files for submission-specific files. The tool's usage context is entirely implied by its name and 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?
The description is consistent with the annotations (readOnlyHint: true) but adds no additional behavioral context. It does not mention details like pagination, ordering, or the structure of the returned items, leaving the agent to infer those. Since annotations already cover the read-only nature, the description contributes minimal extra 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 sentence with no redundant words or extra detail. It is front-loaded and directly states 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?
For a simple list tool with only two required parameters and no output schema, the description gives a minimal but sufficient understanding. However, it omits any mention of the return format, pagination, or what 'items' entails, which could be helpful given the lack of an output schema. It meets the minimum bar but lacks depth.
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 course_id and module_id have clear in-schema descriptions ('The Canvas course ID' and 'The Canvas module ID'). The tool description does not add any further nuance about these parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all items within a module' clearly states the action (list) and the resource (items within a module). It distinguishes from sibling tools like list_modules (which lists modules) and create_module_item (which creates an item), so 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 guidance on when to use this tool versus alternatives. It does not mention when to prefer this over list_modules or get_module, nor does it state any prerequisites or context such as needing a course and module ID beforehand. There is no 'when to use' or 'when not to use' information.
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 and openWorldHint=true, so the description adds no behavioral detail beyond these. It does not mention pagination, response structure, or any caveats, so it provides little extra value over 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, clear sentence with zero fluff. It is front-loaded with the action and scope, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema and adequate annotations, the description is minimally sufficient. However, it does not mention return format, pagination, or related behavior, which could be helpful for a complete tool specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter account_id is fully described in the schema (100% coverage) as 'The parent Canvas account ID'. The description does not add extra meaning beyond what the schema already provides, 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 'List sub-accounts under a given Canvas account' with a specific verb and resource. It distinguishes from sibling tools like list_accounts by scoping to sub-accounts under a specific parent, though it does not explicitly reference 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?
Usage context is implied: this tool is for listing sub-accounts under a given account. There is no explicit guidance on when to use this versus similar tools like list_accounts or get_account, and no exclusions are mentioned.
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 detail beyond the one-line action. It does not disclose overwrite semantics, whether it is a partial update, or what response is returned; the annotations provide the destructive clue, but the description itself offers no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the action and target clearly in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nine parameters and no output schema, so some gaps remain: the description does not clarify partial-update behavior, return values, or when updates are destructive in practice. However, the schema and annotations cover parameter meaning and safety, making this minimally 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 parameter meanings are fully documented in the schema. The description adds no parameter-level explanation, which aligns with the baseline of 3 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 uses a specific verb ('Update') and clearly identifies the resource ('existing New Quiz (LTI) in a Canvas course'). This distinguishes it from sibling tools like create_new_quiz, delete_new_quiz, and get_new_quiz_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 create_new_quiz or update_assignment. It does not mention prerequisites, exclusions, or situations where another tool 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?
The annotations include destructiveHint=true, which signals that the tool modifies data. The description does not add additional context about side effects, permissions, or reversibility, but it does not contradict 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, concise sentence with no unnecessary words or repetition. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the tool's return value or any preconditions. Since there is no output schema, the description should hint at what the response will be (e.g., success message or comment object), but it does not, leaving a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with clear descriptions (e.g., 'The Canvas course ID'). The description adds no additional meaning beyond the schema, so it remains at 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 'Add a text comment to a submission' and identifies the resource (submission). It is specific and distinguishes from similar tools like grading or rubric submission.
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 context on when to use this tool versus alternatives, such as grading or other commenting tools. It lacks any 'use when' or 'instead of' 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 indicate readOnlyHint=true and openWorldHint=true, so the description doesn't need to disclose mutating behavior. It adds no further behavioral context (e.g., error conditions, what 'details' include). It does not contradict annotations. With annotations covering safety, a score of 3 is reasonable.
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 that is front-loaded with the verb and resource. It is concise and has no waste, though it is slightly vague about what 'details' means.
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 has a small parameter set (3), full schema descriptions, and no output schema, the description is adequate but could specify what fields are returned or any prerequisites (e.g., that the context must exist). It is complete enough for a straightforward retrieval.
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 complete descriptions for all three parameters, covering context_type, context_id, and outcome_group_id. The description merely restates 'account or course context', which adds minimal semantic value beyond the schema. With 100% coverage, 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 'Get details for a specific outcome group in an account or course context' clearly identifies the verb (get) and resource (outcome group), and distinguishes it from siblings like 'list_outcome_groups' by emphasizing 'specific' outcome group. However, it doesn't explicitly contrast with sibling tools that also fetch outcome-related data.
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: to retrieve details of a single outcome group, given context type/id and outcome_group_id. It does not explicitly state when not to use this tool (e.g., when listing groups) or mention alternatives. Given the clear parameters, it provides basic context but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool's read-only nature is known. The description adds no additional behavioral context such as pagination, return format, inclusion of correct answers, or response structure. It essentially restates the title without disclosing new traits.
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 directly conveys the tool's purpose without any fluff. It is appropriately sized for a tool with only one parameter and a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-described parameter and no output schema, the description is mostly complete. It could benefit from noting whether the returned data includes question text, correct answers, or just the student's submitted choices, but the openWorldHint and readOnlyHint annotations mitigate the lack of output schema detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for the single parameter (quiz_submission_id), so the baseline is 3. The tool description does not add any further parameter semantics beyond what the schema already states.
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 a student's answers for a specific quiz submission. It uses a specific verb ('Get') and resource ('student's answers for a quiz submission'), distinguishing it from siblings like get_quiz_submission_events (which retrieves events) and get_quiz_question_responses (which focuses on question-level responses).
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. Sibling tools such as get_quiz_submission_events and get_quiz_question_responses could be confused, but there is no explicit or implied indication of when to choose this tool over them.
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 readOnlyHint: true, so the read-only nature is known. The description adds no extra behavioral context (e.g., side effects, error conditions, or relation to other outcome groups). With annotations lowering the bar, a neutral score is appropriate as nothing contradicts.
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 directly states the function. There is no extraneous wording, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description adequately conveys the tool's purpose. It does not explicitly mention the return value or potential errors, but given the simplicity and lack of an output schema, it is sufficiently complete for an agent to understand the core 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 already fully describes both parameters (context_type and context_id) with clear text. The description adds no additional meaning or usage notes about these parameters, so the baseline of 3 is given since schema coverage is 100%.
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 the specific resource ('root outcome group') within a context, which distinguishes it from general outcome group tools. However, it does not explicitly differentiate from potential alternatives like 'list_outcome_groups' or 'get_outcome_group', so it falls short of a perfect 5.
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 outcome-related siblings. It does not mention any conditions, exclusions, or alternative tools, offering no usage context beyond the inherent meaning of 'root'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, signaling a safe read operation. The description reinforces the scoping ('assigned to a specific submission') but doesn't add beyond that. No contradiction; the description provides adequate, if minimal, additional context for a simple read.
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 conveys the action and scope efficiently with zero wasted words. Ideal length for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema coverage and read-only annotations, the description is complete for its purpose. Slight ambiguity remains about whether 'peer reviews assigned to a submission' means reviews on the submission or by the submission's author, keeping it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters documented as Canvas IDs), satisfying the baseline. The description adds the conceptual model—these three IDs together identify one submission—but doesn't need to say more given the schema covers formats.
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 ('List') and clearly identifies the resource ('peer reviews assigned to a specific submission'). It's distinct from the sibling 'list_peer_reviews' by scoping to a submission, though it doesn't explicitly call out the distinction.
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 the similar sibling 'list_peer_reviews' or other review-related tools like 'get_submission'. The context (siblings) shows ambiguity with list_peer_reviews, but the description provides no exclusions or alternative tool mentions.
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 openWorldHint=true, so the safety and scope profile is covered. The description adds little extra behavioral context, such as whether results are paginated or sorted, but the read-only nature is implied via annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action and resource. It is concise and no filler, though it could be slightly more specific about the scope ('directly under') which adds precision without length.
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 and annotations cover safety, the description is adequate but not thorough. It does not explain the return structure (e.g., list of outcome objects) or whether it includes nested outcomes, which could be ambiguous for an agent. However, the complexity is moderate and the schema covers parameters well.
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% coverage of parameter descriptions, so the baseline is 3. The description mentions the three required parameters but does not add extra meaning beyond the schema, such as how outcome_style affects the output or default values. It does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists linked outcomes under a specific outcome group, using a specific verb ('List') and resource ('outcome group outcomes'). It distinguishes from siblings like 'list_outcome_group_subgroups' and 'get_outcome_group', though it could explicitly name those alternatives for clarity.
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 'specific outcome group' and requiring context_type, context_id, and outcome_group_id, but it does not explicitly state when to choose this over sibling tools like 'list_outcome_group_links' or 'get_outcome'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag the tool as potentially destructive, but the description adds no behavioral details beyond 'create a new wiki page.' It does not explain what destructive behavior might occur, any side effects, permissions needed, or whether creating may overwrite or conflict with existing pages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part contributes directly to identifying the operation and the resource involved.
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 straightforward create operation with a fully documented parameter schema and annotations, this is minimally adequate. However, the absence of an output schema, lack of explicit usage alternatives, and unexplained destructive hint leave room for a more 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 all five parameters already have meaningful descriptions. The tool description itself adds no parameter-specific meaning, so the baseline score of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('new wiki page'), and the scope ('in a course'), making it obvious what the tool does. It also distinguishes it naturally from sibling tools like update_page, delete_page, and get_page without being tautological.
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—creating a new page in a course—is implied by the name and description, but the description does not explicitly explain when to prefer this tool over update_page or other page-related alternatives. There is no when/when-not guidance or mention of 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?
The description adds 'This action is permanent,' which is beyond the destructiveHint annotation, but it does not elaborate on other behavioral aspects like side effects, reversibility, or authorization requirements. Given the annotation already flags destructiveness, the added permanence is useful but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and the key constraint (permanence). Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with full schema coverage and destructive annotations, the description is adequate but minimal. It does not mention potential failure conditions, effects on related data, or required permissions, but these are not strictly necessary given the simple operation and 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?
All four parameters are fully described in the schema (100% coverage), so the description does not need to explain them further. It adds no extra meaning beyond the schema, which is adequate as a baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and clearly identifies the resource ('a peer review assignment from a submission'). It is distinct from sibling tools like create_peer_review and list_peer_reviews, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or when not to use it. The description merely states what it does, leaving the agent to infer usage 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?
Annotations already flag destructiveHint: true, but the description adds no context about potential side effects (e.g., overriding existing enrollments, changing user access). The description only states the basic action, leaving the agent without behavioral insights 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 sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and 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 tool has four parameters and no output schema, and the description is minimal. It does not mention default behavior like enrollment_state defaulting to 'invited', potential conflicts with existing enrollments, or the meaning of the destructiveHint annotation. Adequate for a simple operation but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters described in the input schema. The description's mention of 'specified role' reinforces the `type` parameter but adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enroll a user in a course with a specified role' clearly identifies the action (enroll), the resource (user in course), and the key parameter (role). It distinguishes this from sibling tools like remove_enrollment and list_enrollments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage by stating the output action, but it does not explicitly say when to use it versus alternatives like remove_enrollment or list_course_enrollments. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds no additional behavioral context (e.g., pagination, permissions, or response format). It is consistent with the read-only annotation, but does not go 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, concise sentence that is front-loaded with the core action and resource. There is no extraneous wording or repetition; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a read-only list tool with good annotations, but it lacks details about the response structure (since no output schema exists) and does not mention the optional filters like only_assignment_alignments or show_unpublished_assignments. These are left to the schema, which is acceptable 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 descriptions cover 100% of parameters, providing clear meaning for user_ids, course_id, outcome_id, and the two boolean flags. The tool description does not add extra semantic value beyond what the schema already specifies. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves assignment or quiz scores that contributed to an outcome, specifying the resource (scores), verb (get), and scope (for students in a course). It distinguishes itself from sibling outcome tools like get_outcome_results or get_outcome_rollups by focusing on contributing scores specifically.
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 get_outcome_results or get_outcome_rollups. No context is given for filtering by user or course, nor any exclusions or prerequisites. An agent must infer usage from the name and general 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?
Annotations already declare readOnlyHint: true and openWorldHint: true, so the agent knows it is a safe read operation. The description adds minimal behavioral context beyond that—it does not explain return format, aggregation details, or potential performance implications. Since annotations carry the safety burden, the description's contribution is adequate but not rich, meriting a 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, front-loaded sentence that efficiently captures the tool's core function. Every word contributes meaning, with no fluff or redundancy. It is appropriately sized for its 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 tool has 8 parameters (all explained in schema) and no output schema, the description could have provided more context about expected return values or how parameters interact. However, for a simple read-only analytics tool, the description is minimally sufficient—it names the resource and filters. Still, the lack of output description and interplay hints leaves some gaps, so a 3 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?
Schema description coverage is 100%, so each of the 8 parameters is already clearly documented in the schema. The tool description only reiterates the optional filters ('optionally filtered by students or outcomes') without adding syntax, examples, or relationships between parameters. With full schema coverage, baseline is 3, and the description does not exceed that 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's purpose: 'Get mastery distribution analytics for outcomes in a course, optionally filtered by students or outcomes.' This is a specific verb+resource combination and distinguishes it from sibling outcome tools like get_outcome_results or get_outcome_rollups by focusing on 'mastery distribution 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. It does not mention exclusions, prerequisites, or when a different tool might be more appropriate. The only hint is the verb 'Get' and the mention of optional filters, which does not help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, which already signal a safe read operation. The description adds that results are per-student and filterable, but does not disclose pagination behavior, return structure, or any error conditions. With annotations providing the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose and lists optional filters efficiently. No extraneous words or repetition of schema details; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with good schema coverage and no output schema, but it lacks information about pagination, response format, and authentication. Given the complexity and the presence of sibling outcome tools, the description could be more complete by specifying default behavior (e.g., whether all students are returned unless filtered).
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 all parameters have descriptions. The tool description adds the context 'per-student' and 'course' but does not clarify parameter usage beyond the schema. The schema already describes filters like user_ids and outcome_ids, so the description contributes limited additional meaning.
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 'per-student outcome results' for a course, with optional filters. It distinguishes from siblings like 'get_outcome_rollups' by specifying per-student granularity and mentions filters, but doesn't explicitly compare to rollups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving outcome results with filters, but does not specify when to use this versus alternatives like 'get_outcome_rollups' or 'get_outcome_contributing_scores'. It provides context for optional filters but no explicit exclusions or alternative 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 already declare readOnlyHint=true, so the read-only nature is established externally. The description adds only the optional aggregation/filtering behavior and no additional side-effect context, auth requirements, or rate-limit information; this meets the lowered bar but does not exceed 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?
A single front-loaded sentence with the verb and object first; every phrase adds meaning and there is 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?
This is a fairly complex tool (11 parameters, no output schema), and the description provides only a high-level summary. It does not explain what a rollup response contains or how this relates to get_outcome_results, so an agent would need to infer return semantics from the tool name and parameter 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 descriptions cover 100% of the 11 parameters, so the baseline is 3. The description's mention of filtering 'by students, outcomes, and sort options' maps loosely to user_ids/outcome_ids/sort_by but adds no information beyond the detailed schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Get outcome rollups for a course' and mentions optional aggregation/filtering by students, outcomes, and sort options. It is not misleading, but it does not explicitly distinguish this from closely related outcome tools like get_outcome_results or get_outcome_contributing_scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of use is implied: this is the tool for retrieving outcome rollups with optional filters/aggregation. However, the description gives no explicit guidance about when to prefer this over related outcome tools, nor any exclusions or alternative tool 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 already declare readOnlyHint and openWorldHint, so the description does not contradict them. It adds the detail that it returns the HTML body, which is useful, but it does not mention behaviors like missing syllabus handling or authentication requirements. The bar is low due to annotations, and the description provides marginal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, entirely to the point, with no extraneous words or redundancy. It efficiently conveys the purpose without bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description conveys the core functionality. However, it does not explain what the HTML body includes, when it might be empty, or why the user should choose this over overlapping tools. Given the low complexity, it is just adequate but could be more explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, course_id, is fully documented in the schema ('The Canvas course ID'). Schema description coverage is 100%, so the description does not need to add more. It adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the syllabus HTML body for a course, specifying the resource (syllabus) and output format (HTML body). This distinguishes it from sibling tools like 'get_course' or 'list_courses' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 instead of alternatives like 'get_course' or 'list_pages'. It only states what it does, leaving the agent to infer usage from the tool name, but without exclusions or alternative tool mentions.
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 signal idempotent, openWorld, and destructive behavior, lowering the bar for the description. The description adds that grading permissions are required, but it does not elaborate on what destructive means here (e.g., overwriting an existing grade), which is a meaningful gap. There is 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?
Two short sentences deliver the core purpose and the key prerequisite with no filler. The structure is front-loaded, making it easy for an agent to parse quickly.
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 moderate complexity of grading (destructive, idempotent, permission-sensitive), the description covers the basics but not the consequences of overwriting an existing grade or posting a new one. It is adequate for an experienced agent but leaves out useful behavioral details.
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 already documented in the schema. The description adds no additional parameter semantics, 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 uses the specific verb 'Post or update' with the object 'a grade for a submission,' clearly identifying the action and resource. However, it does not explicitly distinguish this from sibling tools like comment_on_submission or score_quiz_question, so it misses full marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Requires grading permissions' provides a useful prerequisite, and the CRUD-like language implies when this tool should be used. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned, leaving usage 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?
The description is minimal and does not contradict the readOnlyHint=true and openWorldHint=true annotations. It adds little beyond the annotations—just 'List all outcome links' which aligns with read-only, but offers no extra detail on pagination, result limits, or side effects. With annotations present, the bar is lower, and it's not misleading, 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 concise sentence with no unnecessary words. It immediately conveys the action and scope, fully front-loaded. There is zero 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?
Without an output schema, the description should hint at the return shape, but it only says 'outcome links' without specifying format or pagination. The parameters explain style options, but the description itself is sparse. It is adequate for a simple read-only list but could benefit from mentioning common use cases or return format.
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 additional parameter meanings beyond what the schema provides. It names 'outcome links' but does not elaborate on the style parameters or context options, so it does not go beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all outcome links') and the context ('account or course'), using a specific verb and resource. It distinguishes from sibling tools like list_outcome_groups or get_outcome_alignments by focusing on 'links' between outcomes and groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to prefer this over get_outcome_alignments or list_outcome_group_outcomes, nor does it provide exclusions or prerequisites. The description only states what it does, not when 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?
The readOnlyHint and openWorldHint annotations already convey the read-only nature of the tool, and the description does not contradict them. However, the description adds no additional behavioral context, such as pagination, ordering, or error behavior, beyond what the annotations already 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?
A single, direct sentence contains all the necessary information without any fluff. It is appropriately minimal for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the potential ambiguity with list_new_quiz_items, a note about scope (e.g., classic vs. new quizzes) or pagination would improve completeness. The description is functional but omits contextual details that would help an agent avoid common mistakes.
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 documents both parameters (course_id, quiz_id) with short descriptions, achieving 100% schema coverage. The tool description adds no additional parameter-level detail, but per the rubric the baseline of 3 is appropriate when the schema already covers parameters fully.
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 ('List') and resource ('all questions in a quiz'), clearly stating the operation. However, it does not clarify whether this applies to classic vs. new quizzes, while sibling tools like list_new_quiz_items suggest such a distinction exists.
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?
Usage is implied by the name and parameter schema, but the description gives no explicit guidance on when to prefer this tool over alternatives like list_new_quiz_items or list_quizzes. No exclusions or contexts are mentioned.
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 mentions the requirement of grading permissions, which is a behavioral prerequisite. It does not disclose any additional side effects beyond what the annotations (destructiveHint) already indicate, and it does not state whether the operation overwrites existing scores or how comments are handled. Thus, it adds minimal transparency beyond 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 concise, consisting of two short sentences that directly convey essential information without redundancy or fluff. It is well-structured 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?
The description covers the core purpose, the optional attempt parameter, and permission requirements. It does not mention return values or error conditions, but given the absence of an output schema and the simplicity of the tool, it is sufficiently complete for a typical user. It could optionally mention whether the comment parameter is supported, but that is not required for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all parameters. The description repeats the attempt parameter guidance that is already present in the schema. It does not add any new semantic meaning or operational context for parameters, such as valid ranges or relationships between them.
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: scoring a specific question in a quiz submission. It distinguishes itself from whole-submission grading by specifying 'specific question', which is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage details for the optional 'attempt' parameter ('Specify attempt to score a particular attempt (omit for latest)') and mentions the required permission. However, it does not explicitly compare against sibling tools like 'grade_submission', leaving the exact context of when to use this tool versus alternatives implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring destructiveHint, idempotentHint, and openWorldHint, the description adds no additional behavioral context beyond restating the action. It does not explain what happens to existing assessments or any side effects of submission, but it does not contradict the annotations 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 a single clear sentence, front-loaded with the verb and resource, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with three required parameters including a nested array, and no output schema. The description omits information about return values, side effects, or whether submission overwrites prior assessments. While annotations and schema cover safety and parameters, the description could be richer for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description reinforces that data contains scores and comments per criterion but adds no new semantic detail 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 'Submit' and the resource 'rubric assessment', specifying it involves 'scores and comments for each criterion.' This distinguishes it from sibling tools like get_rubric_assessment, which retrieves rather than submits.
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 get_rubric_assessment or other grading tools. It does not mention exclusions or prerequisites, leaving the agent to infer usage from the tool name and schema.
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 annotations (openWorldHint and destructiveHint), the description does not add significant behavioral context beyond what is implied by 'create'. It does not mention permissions, side effects, or error handling. The destructiveHint is present but unexplained, and the description does not clarify what happens on creation or if it overwrites anything. Minimal value added over 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 with no fluff. It front-loads the verb and resource, then adds the optional association. Every word earns its place, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects and no output schema, so the description should explain what is returned or any important side effects. It does not mention return values, error conditions, or prerequisites beyond the parameters. Given the complexity, the description is too minimal to be 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 schema fully documents all parameters and nested properties. The description merely restates 'criteria and rating levels' and mentions the optional association, which does not add substantial meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create), the resource (rubric), the context (in a course), and the key components (criteria and rating levels). It also mentions an optional association, distinguishing it from sibling tools like get_rubric or list_rubrics which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it (to create a new rubric) and mentions the optional linking to an assignment, implying it can be used for that purpose. However, it does not explicitly exclude alternatives or mention when not to use it, so it lacks explicit exclusion but has clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds that it returns the full message thread, which is useful context, but doesn't disclose pagination, ordering, or any other behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the purpose and includes the key detail about the full message thread.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, good annotations, and no output schema, the description is complete enough. It states what it returns (full message thread) and the parameter is fully documented in the schema. No significant 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% (conversation_id is described as 'The conversation ID'), so the schema already documents the parameter. The description doesn't add 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.
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 single conversation with its full message thread, using a specific verb ('get') and resource ('conversation'). It distinguishes from sibling tools like list_conversations and get_conversation_unread_count, though it doesn't explicitly name 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 description implies usage for fetching a specific conversation by ID, but doesn't explicitly state when to use it versus alternatives like list_conversations or get_conversation_unread_count. No exclusions or alternative tool names 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 openWorldHint=true, so the safety profile is covered. The description adds a small behavioral detail: it returns graders and assignment IDs for a given date. However, it does not describe output format, pagination, or behavior when no activity exists, providing only minimal additional context 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, tightly scoped sentence with no filler. It front-loads the action and output, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with only two schema-described parameters and no output schema, the description provides the essential purpose and return content. However, it does not clarify the structure of 'graders' (e.g., IDs vs names) or how this tool relates to the sibling gradebook history tools, so there is a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both required parameters (course_id and date), so the schema already documents their meaning. The description adds no new parameter-level semantics beyond implying that the date is used for the day-specific filter.
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 names the resource clearly: 'graders and assignment IDs that had gradebook activity' scoped to 'a specific course date.' This distinguishes it from sibling tools like list_gradebook_history_days and list_gradebook_history_submissions, which operate at a different granularity or content type.
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 related gradebook history siblings, nor does it mention any exclusions or prerequisites. The only implicit usage signal is 'specific course date,' which suggests day-level lookup but leaves the agent to infer the full context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's 'Get' aligns with those. It adds useful context by stating the feed is paginated and that filters/sort are optional, but it doesn't describe the shape of returned entries or pagination behavior. 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?
A single front-loaded sentence states the core action, scope, filters, and sort option with no filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential invocation context: required course scope, optional filters, sort order, and pagination. No output schema exists, but for a selection/invocation purpose the missing return-structure detail is a minor gap. It is complete enough for an agent to select and call 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?
All four parameters are described in the schema (100% coverage), so the description need not add much. It does map 'filtered by assignment or user' to assignment_id/user_id and 'oldest-first' to ascending, but this is mostly paraphrasing the schema. 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 uses a specific verb ('Get'), names the resource ('paginated gradebook history feed'), and scopes it to a course, with optional filters and sort. This clearly differentiates it from unrelated tools, though it doesn't explicitly contrast with sibling gradebook history tools like list_gradebook_history_days.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving gradebook history in paginated form, optionally filtered by assignment or user and sorted oldest-first. It provides no explicit guidance on when to prefer this over list_gradebook_history_days or list_gradebook_history_submissions, so usage context 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds minimal behavioral context beyond 'Get a single item... by item ID' — no error conditions, prerequisites, or relationship to quiz structure. The read-only action is consistent with the annotations; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 14-word sentence that's front-loaded with the action verb and efficiently packed with disambiguation: '(question)' clarifies the domain term, '(LTI)' adds platform context, and 'by item ID' specifies the lookup key. 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 ID-based getter with full schema coverage, read-only/open-world annotations, and no output schema, the description is nearly complete. It covers the resource type, the item scope, the platform context, and the retrieval key. Slightly more (e.g., relationship to the quiz structure) would push it higher, but it's well-suited to its purpose.
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 (item_id, course_id, assignment_id) already has a type and semantic description. The description adds no parameter-specific detail, but per the high-coverage baseline, a 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Get) with a clear resource (a single New Quiz item/question) and scoping ('by item ID'). The word 'single' implicitly contrasts with sibling `list_new_quiz_items`, though it doesn't explicitly name the alternative, keeping it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: fetch a single record by ID using the three identifying parameters. However, there is no explicit when-to-use-this vs. alternatives guidance, no exclusionary notes, and no mention of when one might prefer `list_new_quiz_items` instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add behavioral context. It adds the filtering scope but does not mention pagination, result shape, or whether alignments include assignment-level and question-level associations. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and resource, then states optional filters. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with complete parameter documentation and readOnly/openWorld annotations, the description is mostly sufficient. However, it could benefit from clarifying what an "outcome alignment" represents and what the response will include, especially since there is 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 the parameters are already well documented. The description merely restates that student_id and assignment_id are optional filters, adding no meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Get outcome alignments for a course, optionally filtered to a specific student or assignment." It clearly identifies the scope (course) and optional filters (student, assignment), and the term "alignments" distinguishes it from sibling tools like get_outcome_results, get_outcome_rollups, and get_outcome_mastery_distribution.
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 outcome-related tools. It does not mention exclusions, prerequisites, or direct siblings, leaving the agent without selection context beyond the basic 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?
Annotations already indicate readOnly and openWorld. The description adds that it lists 'active' announcements and targets the 'current user,' which is useful but does not introduce any new behavioral guarantees 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, clearly structured sentence that includes examples in parentheses. It is concise and free of redundancy, delivering the essential information 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 adequately explains what the tool does and its scope. It does not mention pagination or return format, but since no output schema is provided and the tool is a simple list operation, the provided detail is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'account_id' parameter with its default and allowed values. The tool description does not add any additional meaning to the parameter, so it remains at 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 that the tool lists active global institution-wide announcements for the current user, with specific examples (maintenance windows, term deadlines, policy notices). This distinguishes it from course-level announcement tools like 'list_announcements'.
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 mention when to use this tool versus alternatives such as 'list_announcements' for course-specific announcements. It provides context but no direct guidance on selection criteria.
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 provide readOnlyHint=true, and the description adds no additional behavioral context (e.g., pagination, response format, or filtering details). It simply restates the read operation without adding 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 a single, concise sentence with no unnecessary words or fluff. It is front-loaded 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?
For a simple list operation with two parameters, no output schema, and read-only annotation, the description is sufficient. It does not mention pagination, but given the simplicity and annotations, it 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 coverage is 100%, so baseline is 3. The description does not elaborate on account_id or search_term, but the schema already provides descriptions for both, making this adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists users in a Canvas account, using a specific verb and resource. It effectively distinguishes from siblings like list_course_users (course scope) and search_users (global search) by specifying 'in a Canvas account'.
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 account-level user listing but gives no explicit guidance on when to use this over alternatives such as list_course_users or search_users. No exclusion criteria 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the tool's non-destructive nature and potential incompleteness. The description adds no further behavioral context (e.g., pagination, filtering, auth requirements) but does not contradict annotations, so a baseline 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, front-loaded sentence with zero filler. Every word contributes to the core purpose, making it highly concise and structured.
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 and only a single parameter, the description is too thin for an agent to fully understand the return value or any limitations (e.g., pagination, fields returned, ordering). It simply states 'list all' without clarifying the nature of the response, which is a notable gap for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (course_id is fully described in the schema). The description adds no additional meaning to the parameter beyond what the schema already provides, so a baseline of 3 is given per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('wiki pages') with explicit scope ('in a course'). It distinguishes from siblings like get_page (single page) and create/update/delete operations, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the phrase 'List all' implies it is for obtaining an overview of all pages. No exclusions or alternative recommendations are provided, making the usage context merely 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?
Annotations indicate read-only, and description adds no further behavioral context beyond the list 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?
One concise sentence without waste, directly stating the function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description implies a list of rubrics, sufficient for a simple 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?
Single parameter course_id is well-described in the schema; description adds no extra nuance.
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 lists all rubrics in a course, distinguishing it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives mentioned; only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not add behavioral details beyond the annotations. The readOnlyHint and openWorldHint already indicate safety and openness, but the description does not elaborate on what 'full details' entails or potential caveats. Given the annotations, this is acceptable but not exemplary.
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 directly conveys the purpose. It contains no redundant information or unnecessary detail, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a basic understanding of the tool but does not elaborate on return structure or edge cases. Given the absence of an output schema, it is acceptable, but it could benefit from mentioning what constitutes 'full details' (e.g., including criteria, mastery levels, etc.) to better guide 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 descriptions for outcome_id and add_defaults are clear and complete. The tool description does not add any extra meaning to these parameters, so it meets the baseline. No additional clarification is needed since the schema already covers them.
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 full details for a specific learning outcome by its ID. It includes a verb (get) and a resource (learning outcome), making it unambiguous. It distinguishes from sibling tools like get_outcome_group or get_outcome_alignments by focusing on a single outcome.
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 have an outcome ID, use this tool. However, it does not explicitly contrast with alternatives like listing outcomes or retrieving outcome groups, nor does it specify when not to use it. Given the large number of sibling tools, more explicit guidance would be beneficial.
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 openWorldHint=true, so the safety profile is covered. The description adds no extra behavior beyond stating it lists groups; it doesn't mention pagination, ordering, or the top-level scope (versus nested). The word 'all' could subtly conflict with openWorldHint, but is not a direct 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 a single, concise sentence that is front-loaded with the action and resource. No redundant language or filler, 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?
Given the simple nature and good schema/annotations, the description is adequate but lacks a key clarification: whether it returns only top-level groups or includes nested subgroups (given sibling tools like list_outcome_group_subgroups). It also omits any mention of pagination or result structure, 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 already describes both parameters with 100% coverage (context_type enum and context_id). The description only reinforces the account/course context without adding new meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('outcome groups') and clearly scopes to 'account or course context', which distinguishes it from sibling tools like get_outcome_group (single group) or list_outcome_group_subgroups (nested groups). It fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: listing all outcome groups for a given context. However, it does not explicitly differentiate from related tools (e.g., get_root_outcome_group) or mention when not to use it. There is implied usage but no exclusions or alternatives stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, which provide safety context. The description adds 'existing assignment', indicating it modifies present records. However, it does not disclose partial update semantics (e.g., only provided fields are changed), error handling, or permission requirements, so added value beyond annotations is minimal but not misleading.
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 ('Update an existing assignment in a course.') with zero wasted words. It is highly concise and immediately understandable.
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 update tool with detailed schema annotations, the description is adequate but not comprehensive. It lacks guidance on return values or update behavior, but the schema covers parameters and annotations cover safety. The overall context is sufficient for an agent to correctly invoke the tool, but there is room for improvement in usage guidance.
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 8 parameters, so the baseline is 3. The tool description adds no additional parameter-level context; it relies entirely on the schema's field descriptions. This is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and resource ('existing assignment in a course'), clearly distinguishing it from sibling tools like create_assignment, delete_assignment, and get_assignment. The phrase 'existing assignment' clarifies that it modifies an already-created assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have an existing assignment to modify), but it does not explicitly state when to prefer it over create_assignment or delete_assignment, nor does it mention alternatives or exclusions. The usage context is clear but not elaborated.
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 openWorldHint: true and destructiveHint: true, which already inform the agent about external interactions and potential destructive behavior. The description adds context about the base64 encoding requirement and that Canvas performs a multi-step upload internally. However, it does not disclose details like overwrite behavior, return values, or failure modes. Given the annotations, the additional context is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no redundant or filler content. Every sentence adds value: the first defines purpose, the second provides an encoding requirement and expectations about internal processing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and a key constraint but omits potentially useful operational details such as return value, error behavior, or handling of existing files with the same name. The schema and annotations provide good baseline coverage, but for an upload tool with no output schema, it would be helpful to know what happens on success or failure. It is adequate for 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%, with all parameters documented, so the schema carries the heavy lifting. The description reinforces that 'content' must be base64-encoded, which is already stated in the schema, and adds no new parameter-specific information. Thus it meets the baseline of 3 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 tool's function: 'Upload a file to a course.' This is a specific verb+resource construction that distinguishes it from sibling tools like download_file, delete_file, and list_files. It adds relevant constraints (base64 content) and a behavioral note about internal multi-step handling.
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 stating its purpose, but it does not explicitly specify when to use this tool over alternatives or mention any exclusions. For example, it doesn't say 'use download_file to retrieve files' or note scenarios where uploads are not appropriate. The usage context is inferred from the tool name and description, but no direct alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral detail beyond the annotations. It does not mention side effects (though annotations already flag destructiveHint), permission requirements, error conditions, or any caveats. The only extra detail is that it returns the created course object, which is a nominal outcome.
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 with no redundant information. Every word contributes to stating the purpose and the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and flat parameters, the description is adequately complete. It states the action and the return value, and the schema provides parameter context. There is no mention of edge cases or error handling, but that is not required for a straightforward creation action.
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 (name, end_at, start_at, account_id, course_code), each with a clear explanation. The tool description does not repeat or add any new meaning to the parameters, 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 ('Create a new course in a Canvas account') and distinguishes it from other sibling tools that create different resources (e.g., assignments, discussions). It also mentions the return value, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any preconditions or context where this tool is preferred. It only states the basic action, leaving the agent to infer usage from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true and openWorldHint=true, so the agent knows the operation may have destructive/external effects. However, the description adds no extra context about what gets destroyed, permissions, reversibility, or side effects. It merely restates the action without elaborating on the noted destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the action directly. It is front-loaded and contains 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 4-parameter assignment tool with full schema coverage and annotations, the description is sufficiently complete. It lacks explicit guidance on edge cases (e.g., overwriting existing peer reviews), but the simplicity of the tool and rich annotations make it 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?
The input schema covers all four parameters with descriptions, so the schema fully documents them. The description adds nothing beyond the schema, so a baseline of 3 is appropriate given 100% 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 uses a specific verb+resource: 'Assign a user to peer-review a submission.' It clearly distinguishes from sibling tools that list or delete peer reviews (list_peer_reviews, delete_peer_review).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: when a user needs to be assigned as a reviewer. It does not explicitly mention alternatives or exclusions, but the verb 'assign' differentiates from list/delete siblings, and the context is unambiguous.
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 and idempotentHint=true, so the destructive nature is covered. The description adds 'This action is permanent,' reinforcing the consequence, but does not disclose cascade effects on submissions/grades or any auth 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 short sentences, front-loaded with the action and resource, followed by the key consequence. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with strong annotations and full schema coverage, the description is sufficient. It states the action, the target, and the permanence; the absence of an output schema is acceptable for a delete 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 documents both parameters with 100% coverage, so the description need not add parameter details. The description's mention of 'an assignment' and 'a course' aligns with the schema but adds no new semantic information beyond 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 ('Delete') with a clear resource ('an assignment') and scope ('from a course'), making the purpose unmistakable. It also distinguishes the tool from siblings like create_assignment, update_assignment, and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an assignment should be removed from a course. However, it offers no explicit guidance about when not to use it or alternatives (e.g., update_assignment for edits instead of deletion).
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, so the description's 'permanent' adds minimal new information. It does not disclose any additional behavioral traits beyond what annotations cover, such as side effects or authorizations required.
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 with no filler. The purpose and key warning are front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and destructive annotation, the description is adequate. It omits potential side effects (e.g., cascading deletion of associated objects) but is acceptable given the simplicity and annotation coverage.
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 sole parameter file_id described as 'The Canvas file ID'. The description adds no extra meaning beyond the schema's parameter documentation, so 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?
The description clearly states 'Delete a file by ID', using a specific verb and resource. It distinguishes from sibling tools like upload_file, download_file, and get_file by focusing on the deletion action.
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 want to permanently delete a file) but does not explicitly mention alternatives or when not to use it. It could benefit from noting that the action is irreversible, but that is also implied by annotations.
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 it retrieves details, which is consistent with readOnlyHint=true. It doesn't add extra behavioral context beyond what the annotation already conveys, such as side effects or permissions. Since annotations cover the safety profile, the description doesn't need more, but it also doesn't add any additional transparency beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the purpose without unnecessary elaboration. It front-loads the action and resource effectively.
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 operation with well-described parameters and readOnlyHint annotation, the description is adequate. It distinguishes from list operations (like list_modules) by explicitly saying 'single module'. However, it could mention what 'details' includes, but given the simplicity, it's complete enough.
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 complete descriptions for both parameters ('The Canvas course ID' and 'The Canvas module ID'), which are clear and self-explanatory. The description adds no further semantic detail beyond what the schema provides, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving details for a single module. It specifies the resource (module) and the action (get details), which distinguishes it from sibling tools like create_module or update_module. The 'by ID' phrase, though vague, is sufficient given the schema clarifies the required identifiers.
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 a specific module by ID, distinguishing from list operations like 'List modules' (which is a sibling). However, it does not explicitly mention when to prefer this over other tools like 'get_course_structure' or any alternatives, nor does it provide context about prerequisites like course enrollment.
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, indicating a safe read operation. The description adds no extra behavioral details (e.g., pagination, error cases, or any side effects). It is consistent with the annotations, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential purpose without redundancy. It is well-structured and immediately front-loads the key 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 one-parameter list operation with no output schema, the description is sufficiently complete. It tells what it does and implies the return of a list. Minor omissions like pagination behavior are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the course_id parameter and has 100% coverage. The tool description does not add any additional semantics or context beyond what the schema documents, so the baseline score 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 (List), the resource (submissions), and the scope (for the authenticated student in a course). It effectively distinguishes itself from sibling tools like list_submissions (which likely covers all submissions) and get_submission (a single submission).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving the current student's own submissions, but it does not explicitly explain when to use this over alternatives like list_submissions or get_my_grades. No exclusions or alternative tool mentions 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 and openWorldHint, so safety is covered. Description adds no further behavioral context like error handling or response format, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no extraneous detail, effectively 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 get operation with annotations and schema, the description adequately conveys purpose, though it could specify what is returned (page object) but that is implied.
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 covers 100% of parameters with descriptions; the tool description adds no additional semantics beyond the schema, meeting 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?
Description states verb 'Get' and specific resource 'single wiki page' with identifier 'URL slug', clearly distinguishing from list_pages and mutating 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?
No explicit guidance on when to use vs. list_pages or other page tools; usage is implied by the singular phrasing but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint:true and openWorldHint:true, so the agent knows it's a safe read operation. The description adds only that it gets details for a single quiz by ID, which is minimal but consistent. Given the strong annotation coverage, the description needn't add much; it could have added context about response shape, but the annotations cover the safety profile.
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, perfectly formed sentence: 'Get details for a single quiz by ID.' Every word earns its place and the main purpose is front-loaded with the verb 'Get'. The description follows the pattern of similar sibling tools, maintaining consistency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-ID tool with readOnlyHint and openWorldHint annotations, complete schema coverage, and no output schema, the description is adequately scoped. It could have mentioned that there are no side effects or that it returns a 404 if not found, but given the strong annotation coverage and standard Canvas REST pattern, this is sufficient for an agent familiar with the Canvas API.
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 (course_id and quiz_id) described. The schema already provides accurate descriptions ('The Canvas quiz ID', 'The Canvas course ID'). The description adds no additional semantic meaning beyond the schema, but that's acceptable given full coverage. It correctly implies both IDs are needed as path 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 uses a clear verb ('Get') plus resource ('quiz') and identifies basic scope ('single quiz by ID'). It is distinguishable from the more specific 'get_new_quiz_item' and the list endpoint 'list_quizzes' among siblings. However, it doesn't explicitly contrast with the similarly named 'get_new_quiz_item' which could confuse agents given the sibling list contains both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context that this retrieves a single quiz by ID is clear, implying use when you need details for one quiz. However, there is no explicit 'when to use' vs alternatives like 'list_quizzes', 'get_new_quiz_item', or quiz submission endpoints. The 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description aligns with a read-only operation. It adds the useful detail that criteria are included in the response, but it does not disclose other behavioral aspects such as possible errors, authentication needs, or response structure.
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. Every word contributes meaning: 'details', 'single rubric', 'by ID', and 'including criteria'.
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 getter with no output schema, the description adequately conveys the primary return content (rubric details including criteria). It could be slightly richer in describing returned fields, but given the tool's simplicity and the strong annotation support, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions for course_id and rubric_id. The description's 'by ID' is redundant with the schema and adds no additional semantic meaning beyond what is already provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'rubric', with clear qualifiers 'single', 'by ID', and 'including criteria'. It distinguishes from sibling tools like list_rubrics (which lists) and get_rubric_assessment (which focuses on assessments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the user must have a rubric ID, providing some usage context. However, the description does not explicitly state when to prefer this tool over siblings like list_rubrics, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. However, it adds no additional behavioral context—such as what constitutes a 'rubric assessment', error conditions, or return format—thus providing minimal value beyond 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 without any redundant words or fluff, perfectly sized for its 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?
With no output schema, the description adequately conveys that the return value is the rubric assessment. It does not detail the structure, but for a simple 'get' this is acceptable given the annotations and clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions like 'The Canvas user ID'. The description itself does not add further meaning to the parameters beyond what the schema already provides, hitting the baseline for good 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 verb 'Get' and the resource 'rubric assessment' with a specific scope ('for a specific student submission on an assignment'). It distinguishes from siblings like 'submit_rubric_assessment' and 'get_rubric' by focusing on assessment 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?
The description provides clear context by specifying when to use the tool (for a specific student submission), but it does not explicitly exclude alternatives like 'get_rubric' for rubric definitions. No conflicting usage scenarios 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 description is consistent with the readOnly annotation, specifying the data returned (page views, participations, submission timeline) without indicating side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the specific data returned, which compensates for the lack of an output schema, but it does not elaborate on use cases or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters with clear definitions, so the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves per-student activity analytics, distinguishing it from course-level or assignment-level 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool instead of alternatives like get_course_analytics or get_assignment_analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond the readOnlyHint annotation by specifying the content type ('upcoming assignments and grading tasks'), but it does not disclose any additional traits like result limits, ordering, or potential exclusions. 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?
A single, front-loaded sentence that directly states the action and scope. Every word adds value, and there is zero 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 no-parameter, read-only tool with annotations covering safety, the description is largely sufficient. It could explicitly mention that it returns all to-do items or note any default ordering, but given the simplicity, this is minor. The description meets the needs for basic usage.
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?
No parameters exist, and schema coverage is 100% (vacuously). The baseline for zero parameters is 4, and nothing in the description detracts from that. The description does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly defines the resource as 'the current user's to-do items', with concrete examples ('upcoming assignments and grading tasks') that help distinguish it from siblings like 'get_my_upcoming_assignments' or 'get_upcoming_events'. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_my_upcoming_assignments or get_upcoming_events. There is no mention of exclusions, prerequisites, or alternative tool recommendations, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, clearly marking this as a safe read operation. The description adds little behavioral context—no details about error handling (e.g., 404 if user not found), rate limits, or the breadth of 'details' returned. It neither adds significant value beyond annotations nor does it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, 8-word sentence that leads with the action verb, is immediately scannable, and contains zero unnecessary words. It could not be more 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 extreme simplicity of the tool—one parameter, no output schema—the description provides sufficient context for a proficient agent. The openWorldHint suggests it's safe to use in most contexts. A slightly more explicit mention of what 'details' includes (e.g., profile fields, avatars) would push it higher, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter user_id is fully documented in the schema with type and description, giving 100% schema coverage. The description's 'by ID' simply restates the parameter's purpose without adding new semantics. With full schema coverage, the baseline of 3 is appropriate; no additional explanation or usage examples are offered.
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?
Clear subject-verb-object: 'Get details for a single user by ID.' The verb 'Get' plus the unambiguous resource 'user' and the scoping 'by ID' make the purpose immediately obvious. It clearly differentiates from siblings like search_users (which searches) and get_profile (which retrieves the current user).
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 ID is known and details are needed, but it offers no explicit when-to-use guidance or mention of alternatives such as search_users or get_profile. Unlike the high-scoring get_calls example, no alternative is named, so an agent must infer the appropriate context on its own.
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 openWorldHint=true, covering safety and scope. The description adds minimal behavioral detail beyond stating 'all' and 'in a course,' which are already implied by the name and parameter. It does not describe return format, pagination, or any limitations, but given the annotations, 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, clear sentence with no redundancy or filler. It front-loads the main purpose and is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and readOnlyHint annotations, the description adequately explains what the tool does. It could benefit from mentioning return format or distinguishing from list_announcements, but it is generally comprehensive enough for an agent to execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter course_id is well-described in the schema as 'The Canvas course ID.' The description adds no additional meaning to the parameter, so a baseline score of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('discussion topics') with a clear scope ('in a course'). It distinguishes itself from siblings like get_discussion (single topic), create/update/delete (mutations), and post_discussion_entry (entries), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all discussions, but does not explicitly state when to use this tool over alternatives such as get_discussion or list_announcements. No exclusions or alternative guidance is provided, so the usage context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint: true and openWorldHint: true annotations present, the bar is lowered. The description is consistent with these annotations (listing is read-only) and adds a small behavioral detail: it returns 'all' folders in the course rather than a filtered subset. It doesn't contradict the annotations, but it also doesn't disclose pagination, recursion, or ordering 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?
Six words, front-loaded with the action, zero wasted verbiage. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter list operation with readOnlyHint and openWorldHint annotations, this is nearly complete. A bit more context on whether nested/child folders are included would push it to a 5, but the simple surface area makes the current description 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 coverage is 100% (course_id: 'The Canvas course ID'), and the description adds no parameter-level detail. This is the baseline 3 where the schema does the heavy lifting; the description doesn't need to compensate.
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?
'List all folders in a course' uses a specific verb (List), a clear resource (folders), and explicit scope (all in a course). It's unambiguous and distinguishes from the sibling `list_files` by resource type, though it doesn't explicitly contrast naming concerns.
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?
There is no explicit guidance on when to use this tool vs. alternatives or when not to use it. The usage is implied by the name and phrasing, but no exclusions, prerequisites, 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?
Annotations already provide readOnlyHint and openWorldHint, so the description carries less burden. It adds the scoping detail of 'all groups' but does not disclose pagination, response format, or any other behavioral nuances. It is consistent 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, clear, and front-loaded sentence that efficiently communicates the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and read-only annotations, the description is adequately informative. The absence of an output schema means the return structure is not explicitly described, but it is largely predictable for listing groups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of course_id as 'The Canvas course ID'. The description itself adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'groups' with scope 'in a course', clearly distinguishing it from the sibling tool 'list_group_members' which lists members of a group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when groups in a course are needed, but provides no explicit guidance on when to use this tool versus alternatives like list_group_members or list_courses. No 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the 'immediate' scope (non-recursive), but it does not disclose pagination behavior or response structure, which would be useful for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, no filler words. Extremely concise and clear.
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 with three well-described parameters and read-only annotations. The description conveys the core behavior clearly. It omits response format and pagination details, but given the lack of output schema and the straightforward 'list' semantics, 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 coverage is 100% with descriptions for all three parameters, so the baseline is 3. The description does not add additional parameter semantics beyond the schema; it only restates the context of being under a specific outcome group.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with the resource 'immediate child outcome groups' and scopes it to 'under a specific outcome group.' This clearly distinguishes it from sibling tools like get_outcome_group (gets one group) or list_outcome_groups (likely lists all groups).
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?
No explicit alternatives or when-not-to-use conditions are given. The description implies usage when you have a specific outcome group ID and need its direct children, but it does not mention when to use list_outcome_groups or get_root_outcome_group instead. 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read behavior is covered. The description adds no additional behavioral context such as pagination, ordering, 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?
The description is a single clear sentence that front-loads the action and resource. Every word is necessary, 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 low-complexity read-only list operation, the description combined with annotations and 100% schema coverage is sufficient. There is no output schema, but the lack of return-format detail is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with 100% description coverage, including 'The Canvas course ID' and 'The Canvas assignment ID'. The description adds no parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'peer reviews' and clearly scopes them to an assignment in a course. This distinguishes it from sibling tools like get_submission_peer_reviews, which target submission-level 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving all peer reviews for a given assignment. However, it does not explicitly state when to prefer this over get_submission_peer_reviews or mention any exclusions or alternative 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?
readOnlyHint=true and openWorldHint=true are already provided in annotations, so the description doesn't need to repeat safety. It adds minimal extra context beyond the name, only confirming it lists all submissions. No mention of pagination or return format, but the annotation coverage lowers the burden.
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 redundant words. It is front-loaded and directly states 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 list tool with only two parameters and read-only annotations, the description is sufficient to convey the core function. It doesn't explain return structure, but no output schema exists and the name implies a list of submissions. Minor gaps like pagination are not disclosed, but overall adequacy is high.
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 as 'The Canvas quiz ID' and 'The Canvas course ID'. The description text adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('submissions for a quiz'). It distinguishes itself from sibling tools like list_submissions (which likely handles assignment submissions) and other quiz-related tools by specifying 'for a quiz'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a quiz' implies when to use this tool, but it does not explicitly state alternatives or exclusions. There is no guidance on when not to use it or which sibling tools to prefer in other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and openWorldHint, so the description does not need to reassert safety. It adds no additional behavioral context such as pagination, sorting, or permission requirements, but for a simple read-only listing tool the existing annotations cover most of the burden.
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 or redundant wording. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one required parameter, the description is adequately complete: it states the resource, scope, and action. It does not mention pagination or return value shape, but given the simple read-only nature and good annotations, this is a minor gap rather than a critical omission.
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 course_id is fully documented. The description does not add material parameter nuance beyond the schema, but the schema already provides sufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all quizzes in a course') and clearly distinguishes this listing tool from sibling create/update/delete/quiz-detail tools. It communicates both the operation and the 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 makes the basic use case clear: list quizzes for a given course. However, it does not explicitly mention when to prefer this over related tools like list_new_quiz_items or get_quiz, so alternatives are only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no mutations, so the description's simple phrase adds no further behavioral disclosure. There is no mention of pagination, sorting, or enrollment status filtering, which would be useful for a list operation. No annotation 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 a single, short sentence that perfectly captures the tool's purpose with no wasted words. It is front-loaded and 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?
The tool is a simple list operation with a single parameter and a clear purpose. While the description doesn't explain return values (no output schema exists), the tool's richness is limited, so the given description is reasonably complete for an agent to make an informed selection. A small note about pagination or enumeration could improve, but it is not essential for basic understanding.
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 the only parameter course_id is well-described in the schema as 'The Canvas course ID'. The description adds no additional semantics beyond that, but given the high coverage, 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 states a specific verb ('List') and resource ('all students enrolled in a course'), which is clear and unambiguous. However, it does not explicitly distinguish itself from the nearly identical sibling tool 'list_students_needing_attention' or other student-related listing tools, though the course_id parameter provides some 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 usage in a course context ('enrolled in a course') and the required course_id parameter makes it clear it is for course-scoped queries. It does not explicitly state when not to use it versus alternatives like 'list_course_users' or 'list_students_needing_attention', but the scope is reasonably obvious.
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 provide destructiveHint: true, indicating a write operation. The description adds the context that it is a 'reply,' which is useful. However, it does not disclose any other behaviors, such as permission requirements, whether the reply is immediately visible, or potential side effects. Given the annotations cover the destructive aspect, the description meets the minimum bar but does not enrich 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 a single, focused sentence: 'Post a new entry (reply) to a discussion topic.' It is concise, front-loaded with the action, and contains no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write operation with only three required parameters, all documented in the schema, and no output schema required, the description is nearly complete. It clearly states the purpose and is backed by strong schema coverage and annotations. The only minor gap is the lack of explicit mention that this operation requires an existing discussion topic or any caveats about message formatting, but these are implicit given the tool's name and parameter descriptions.
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 all three parameters (message, topic_id, course_id) with clear descriptions, achieving 100% coverage. The description does not add any additional meaning or usage context for the parameters. Since the schema carries the burden fully, the baseline score of 3 applies, and the description offers no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Post a new entry (reply) to a discussion topic.' It uses a specific verb and resource, and distinguishes this from sibling tools like create_discussion (which creates a topic) and update_discussion (which modifies one). The mention of 'reply' clarifies the specific operation intended.
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: it is used to post a reply to a discussion topic. However, it does not explicitly advise when to use this over alternatives, such as create_discussion for new topics or list_discussions for browsing. It lacks explicit when-not-to-use guidance or comparison with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, and the description adds the specificity of searching four content types. It does not contradict annotations, but it discloses little beyond that. The openWorldHint is not addressed, and no return behavior or pagination details are 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 sentence that is front-loaded with the primary action ('Search for content within a course') and contains no superfluous information. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with full schema coverage and read-only annotations, the description is largely complete. It states the scope (within a course) and the content types searched. It omits return format, but that is not essential for a search tool. The tool is straightforward and the description covers the essential facts.
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 descriptions for all three parameters. The description adds no additional meaning beyond what the schema already provides (e.g., content_types enum is already listed). 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 purpose: 'Search for content within a course' and enumerates the content types searched (pages, assignments, discussions, announcements). This distinguishes it from sibling tools like list_pages or view_course_structure, which are for listing or viewing structure rather than keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when searching for content by keyword) but does not explicitly mention alternatives or exclusions. It provides clear context (within a course) but no guidance on when not to use it or when to prefer other tools like list_* functions.
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 (openWorldHint: true, destructiveHint: true) already signal side effects and external integration. The description adds the 'LTI' context, which substantiates the openWorldHint, and the modern-vs-classic engine positioning is useful. However, it doesn't address behavior beyond the schema/annotations such as idempotency, failure modes, or publishing effects. Reasonable value added over annotations, but nothing striking.
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 tight sentences with zero waste. The first sentence front-loads the action and scoping; the second sentence handles differentiation and points to the alternative. Every word contributes value - exemplary economy of language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 8 params (2 required), 100% schema coverage, no enums, and annotations signaling side effects, the description covers the essentials: what it creates, where, and how it differs from the sibling create_quiz. Gaps: no mention of what the tool returns on success (no output schema exists to clarify), nor idempotency semantics - especially relevant given destructiveHint: true. Adequate but not comprehensive for an agent deciding whether to call this vs. understanding consequences.
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 free-text description adds no parameter-specific meaning beyond what the schema documents, but it doesn't need to - the schema already fully documents all 8 parameters. The description's engine distinction (New vs Classic) could theoretically imply different parameter behavior, but that connection isn't made explicit.
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 a specific verb+resource ('Create a New Quiz (LTI) in a Canvas course'). Explicitly distinguishes itself from the sibling create_quiz by naming the alternative and its use case ('for Classic quizzes use create_quiz'), which is exactly the type of sibling differentiation that merits full marks.
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?
Explicitly names the key alternative (create_quiz) and provides a when-not rule ('for Classic quizzes use create_quiz'). Could be a 5 if it elaborated on when New Quizzes vs Classic is appropriate (e.g., feature requirements), but the primary decision rule for the agent is clear and actionable.
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 explicitly states 'This action is permanent,' which is crucial behavioral information beyond the annotations (destructiveHint=true, idempotentHint=true). It adds context that deletions are irreversible. It does not mention auth requirements or side effects on quiz structure, but the permanence is a strong plus.
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, both essential: the first defines purpose and scope, the second adds critical behavioral context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and the annotations, the description is quite complete. It notes permanence, which many destructive operations lack. It could mention prerequisites (like existence of the quiz) but the schema already requires all IDs, and the output is likely void. Overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, documenting all three parameters. The description does not add parameter-level details, but the schema is sufficient. The description's 'permanent' note complements the parameter semantics by emphasizing the irreversible nature, which is valuable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an item (question)') and the resource ('a New Quiz (LTI)'), distinguishing it from siblings like delete_new_quiz (which deletes the quiz itself) and get_new_quiz_item. It is specific and concise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., delete_new_quiz_item vs delete_new_quiz). The context implies it's for deleting individual questions within a New Quiz, but no explicit guidance on when not to use it or alternative tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's role in behavioral disclosure is minimal. It adds the scope qualifier 'accessible to the authenticated user' but does not describe output format, pagination, or other behavioral traits. The description is not contradictory and adds slight context, so a moderate score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It front-loads the action and resource, and the scope qualifier is concise. No 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?
Given the lack of an output schema, the description could provide more detail about what an 'account' entails (e.g., fields like ID, name). However, the tool is simple, and the description covers the core behavior. The scope qualifier adds some context, but it does not specify return structure or any additional behavioral nuances, leaving some gaps.
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?
There are zero parameters, so the input schema is empty and the description does not need to compensate. The description adds no parameter-specific information because none exist; a baseline of 4 is justified.
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), resource (accounts), and scope (accessible to the authenticated user). It distinguishes itself from sibling tools like list_sub_accounts (which lists sub-accounts) and get_account (which fetches a single account).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need all accounts for the user) but does not explicitly contrast it with alternatives like list_sub_accounts or get_account. No when-not-to-use guidance is provided, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only 'all' and 'in a course', which is minimal extra behavioral context beyond what annotations and the course_id parameter already imply. No additional traits like return format, pagination, or filtering behavior are disclosed, but none 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, front-loaded sentence with no filler. Every word contributes meaning: 'List', 'all', 'announcements', 'in a course'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter, read-only list tool with readOnlyHint and openWorldHint annotations and no output schema, the description is complete. It clearly conveys the operation and scope, and nothing critical is missing for selecting and invoking 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% (course_id is fully described as 'The Canvas course ID'). The description repeats the course concept but does not add new meaning beyond the schema. The baseline of 3 applies when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('all announcements') and scope ('in a course'). It unambiguously states what the tool does and is distinct from sibling tools like list_discussions or list_calendar_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need announcements for a given course. However, it provides no explicit guidance on when to prefer this over alternatives, prerequisites, or pagination/result-limit considerations. There is no sibling announcement tool, so the lack of explicit alternatives is less critical, but still missing.
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 and openWorldHint, so the safety profile is covered. The description adds the sorting behavior ('most recent first') and the 'all' scoping, but it does not mention pagination or return format. With annotations present, this level of additional context is adequate but not extensive.
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 provides all necessary information without redundancy. Every word contributes value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with one well-documented parameter and annotations for safety and scope. The description, combined with the schema and annotations, gives the agent sufficient context to select and invoke the tool correctly. No output schema is present, but the purpose and behavior are fully 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 input schema fully describes the only parameter (course_id) with 'The Canvas course ID'. The description's phrase 'for a course' aligns with the schema but adds no new semantic meaning. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource ('content migrations') and scope ('for a course'), plus ordering ('most recent first'). It distinguishes itself from the singular sibling get_content_migration by explicitly covering all migrations for a course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving all content migrations for a specific course, but it provides no explicit guidance on when to choose this over alternatives such as get_content_migration for a single migration or list_content_exports for exports. The context is clear but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description consistently says 'List all enrollments.' It adds contextual detail by specifying the authenticated-user scope and that filters mirror the Canvas endpoint, though it does not dwell on pagination or response shape, which is acceptable given 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, using two sentences to convey the core action, scope, and a useful pointer to the API reference. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with all 6 parameters documented and readOnly annotation supplied, the description is sufficiently complete. It clarifies the user scope, optionality/Canvas correspondence, and explicitly indicates the result is a list of enrollments. The lack of an output schema does not create ambiguity here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds that filters and includes are an optional mirror of the Canvas endpoint, but does not introduce meaning beyond the schema. This matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists all enrollments for the authenticated user across courses, using a specific verb and resource scope. It distinguishes from sibling tools like list_course_enrollments by explicitly noting the cross-course, self-scoped behavior, and references the exact Canvas API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is scoped to the authenticated user's enrollments across all courses, providing context on when to use it. It does not explicitly name alternatives or provide exclusions, so it misses full guidance, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description need not repeat that. However, it does not add any behavioral context beyond the purpose, such as pagination, ordering, or potential limitations. For a simple list operation with safety annotations, the description is adequate but not enriched, matching the TDQS 4.3 baseline 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, front-loaded sentence with no wasted words. It clearly communicates the essential action in a compact form, achieving high conciseness and structure.
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 parameter, no output schema, and clear read-only annotations, the description is complete. It fully conveys the tool's purpose without requiring additional context. The simplicity allows for completeness at this minimal level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter group_id is described as 'The Canvas group ID'). The tool description does not add any parameter information beyond what is already in the schema, so it meets the baseline of 3 for high schema coverage with no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all members of a group'), making it distinct from siblings like 'list_groups' (which lists groups) and 'list_course_users' (which lists users in a course). The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it is implied that one uses this when needing group members, there is no guidance on context, exclusions, or comparisons with sibling tools that also return user lists. This is a minimal viable level of implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no additional behavioral details beyond the annotation's destructiveHint. It does not mention side effects like creating a conversation thread, sending notifications, or requiring specific permissions, which would be useful 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, succinct sentence with no redundant wording, effectively conveying the tool's purpose without unnecessary detail.
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 and the absence of an output schema, the description sufficiently covers the essential functionality without needing to explain return values or complex behaviors.
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 includes concise descriptions for all three parameters (body, subject, recipients), and the description does not add any extra semantic meaning or clarify parameter relationships beyond what is already provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (send), the object (new conversation message), and the target (one or more recipients), making it unambiguous and distinct from sibling conversation tools that list or retrieve conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when sending a new message) and is straightforward, though it does not explicitly contrast with alternatives like replying to an existing conversation. However, the term 'new' clarifies the intended use case.
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 and openWorldHint=true, so the description's mention of 'update' aligns with that. The description adds the specific update operations (rename, reposition, publish/unpublish), which gives some practical insight, but it does not disclose side effects, permission requirements, or the behavior when only some fields are provided. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose and key operations. It is front-loaded with the verb and resource, and there is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with destructiveHint and no output schema, the description is minimal. It does not specify whether the update is partial (only provided fields) or full (must provide all), nor does it mention any prerequisites or consequences. The schema covers parameter details, but the behavioral implications of updating a module (e.g., effect on module items) are not addressed. Given the relatively simple scope, it is adequate but 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 covers all 5 parameters with clear descriptions (name, position, published, course_id, module_id). The description reiterates these via 'rename, reposition, publish/unpublish' but adds no additional meaning beyond what the schema already provides. 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 tool's purpose: updating an existing module, and even enumerates the specific operations it supports (rename, reposition, publish/unpublish). This distinguishes it from sibling tools like create_module (for new modules) and get_module (for viewing).
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 'existing module' implies it is for modifying modules that already exist, which effectively contrasts with create_module. It lists the types of updates allowed, giving context on what it can do. However, it does not explicitly mention when not to use it or provide direct alternatives beyond implicit contrast.
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 destructiveHint: true, but the description adds 'This action is permanent,' which provides additional context about irreversibility beyond the annotation. This adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose and adding the permanence note. Every word earns its place with zero 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 simple delete operation with two fully documented parameters and destructive annotations, the description covers the key aspects including permanence. It does not mention prerequisites like page existence or cascading effects, but for this tool, 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?
The input schema provides 100% coverage for both parameters (course_id and page_url), so the description does not need to add parameter details. The description does not enhance parameter understanding beyond the schema, but the high coverage warrants a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a wiki page from a course' with a specific verb and resource, distinguishing it from sibling tools like create_page, update_page, get_page, and list_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?
Usage is implied: the description indicates this tool is for deleting a wiki page, but it does not explicitly mention when to use it vs alternatives or any exclusions. It does not name alternative tools like update_page for modifications.
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 aligns with the readOnlyHint annotation and adds value by indicating that optional fields like submission, overrides, and all_dates are requested via include rather than returned by default. It doesn't reveal additional behavior such as response shape, error conditions, or rate limits, so it provides only partial transparency 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 two concise sentences with front-loaded purpose. Every word earns its place; no redundant 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?
Given the read-only, single-resource retrieval nature and rich schema descriptions, the description is sufficient for an agent to call this tool correctly. The absence of an output schema is not a large gap because the tool name and 'get details' wording convey the expected return type, but the description could add a little more context about how actual include returns are shaped.
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 already have descriptions. The tool description reinforces the include parameter's usage but does not add new semantic details or clarify formatting, types, or relationships beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a single assignment by ID'), distinguishing it from list-oriented sibling tools like list_assignments and get_assignment_analytics. The mention of optional include fields adds further scope and purpose specificity.
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 positions this tool as the way to fetch details for a single assignment by ID and instructs the agent on how to request optional fields via include. It does not name alternative tools or provide explicit non-use cases, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates no side effects, and the description adds that it returns counts by event type. However, it does not disclose potential limitations (e.g., date ranges, pagination, or error behavior) beyond the basic read-only nature, so it partially relies on 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 brief, with two sentences that directly state the function and the return value. No unnecessary words or repetition; it is well-structured for a simple getter.
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 explains the return value ('counts of recent events grouped by type') which is useful given there is no output schema. It provides enough context for a consumer to understand the tool's purpose and expected result, though it does not detail the exact response structure.
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 single parameter 'course_id' is described in the schema as 'The Canvas course ID', which is clear and complete. The description does not add extra nuance, but given full schema coverage, the parameter semantics are well understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a summary of recent activity in a course'), and it specifies the output type (counts grouped by type). This distinguishes it from other course-related tools like listing assignments or getting a specific assignment.
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 indicates what the tool does but does not specify when to use it compared to alternatives (e.g., checking individual activity or using a dashboard stream). It implies a high-level overview but lacks explicit guidance on scenarios or prerequisites.
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 matches the non-mutating nature implied by the description. The description adds no further behavioral detail but 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, well-structured sentence that efficiently communicates the tool's purpose and output.
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 specifies the return type (daily counts) adequately, but lacks details on optional parameters such as time range or filtering. Given the tool's simplicity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a clear description for course_id, so the parameter is fully understood without additional explanation in the tool 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 it retrieves course-level activity analytics and specifies the exact output (daily page view and participation counts), making it distinguishable 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_student_analytics or get_course_activity_stream, leaving the choice ambiguous.
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 agent knows this is a safe read operation. The description adds no additional behavioral details beyond the basic retrieval action, which is acceptable but not enriching.
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, concise sentence states the purpose and required identifier. No filler or redundant information is present.
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 getter with well-annotated read-only behavior and fully documented parameters, the description is adequate. The absence of an output schema means details about the returned fields are not covered, but this is not critical for a basic retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (topic_id, course_id) already described. The description adds no new parameter semantics, 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 'Get' and resource 'discussion topic' with scope 'by ID', clearly distinguishing it from create/update/delete/list operations. It is unambiguous and immediately understood.
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 'by ID' clearly indicates the tool is for retrieving a single, specific discussion topic when its ID is known. This provides clear context for use, though it does not explicitly mention alternatives 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?
The description adds the state requirement but largely relies on annotations (readOnlyHint=true) to convey that it's a safe read operation. It doesn't discuss edge cases or error behavior, but with annotations present, the additional context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action ('Get the selective import tree for a migration') and includes a brief condition. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with three parameters and no output schema, the description adequately conveys the purpose and the key state condition. It doesn't detail the tree structure but is sufficient for an agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage). The tool description adds no additional parameter semantics beyond what's already provided in 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 retrieves the selective import tree for a migration, specifying the resource and action. It also mentions the state condition ('waiting_for_select'), which differentiates it from other migration-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for use: only meaningful for migrations in the 'waiting_for_select' state. This gives guidance on when to invoke it, though it doesn't explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds useful scoping behavior ('If course_id is omitted, returns grades across all enrolled courses') but does not disclose any return format or additional side effects; this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. Every clause contributes useful information about scope and optionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with strong annotations, the description is largely complete. The main gap is that 'grade data' is somewhat unspecified (e.g., points, percentage, letter grade), but the absence of an output schema and the low complexity keep this from being a major deficiency.
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 schema already explains course_id as 'The Canvas course ID (omit for all courses)'. The description essentially repeats the same parameter guidance, so it adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get grade data for the authenticated student', which uses a specific verb and resource and immediately establishes it as a read tool for the current user's grades. The optional course_id behavior further clarifies scope, and this clearly distinguishes it from sibling tools like grade_submission or project_grade.
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 tells the agent when to use the tool: to retrieve grade data for the authenticated student, with explicit behavior when course_id is omitted. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for selection among grading-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds that the tool returns ok/error status, which is useful, but provides no further behavioral details (e.g., non-mutating confirmation, error handling specifics). The description is consistent 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?
A single sentence that fully conveys the tool's function and return format. Every word earns its place; 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 health check with no parameters and no output schema, the description is complete enough: it states what it checks (reachability, token) and what it returns (ok/error). A minor gap is that it doesn't clarify what 'error' may indicate (e.g., network issue vs. invalid token), but this is not critical for a basic health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter meaning beyond the schema. Baseline for 0 params is 4, and the description correctly focuses on purpose and output rather than 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 tool checks if the Canvas API is reachable and the token is valid - a specific verb+resource with distinct purpose. It stands apart from all sibling tools, none of which are health checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for verifying connectivity and token validity, but does not explicitly state when to use it versus alternatives or any preconditions. It is self-explanatory but lacks explicit guidance on timing or exclusion.
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 mark this as read-only and open-world, and the description ('List courses') is consistent with those annotations. However, the description adds little beyond the account scoping already implied by the parameter schema; it does not mention pagination, ordering, search behavior, or output shape. No contradiction with annotations 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 a single, front-loaded sentence with no filler or repetition. It communicates the essential purpose efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with two fully described parameters and safe annotations, the description is mostly complete. It does not detail pagination or return structure, but the absence of an output schema places a moderate burden on the description; still, the core behavior is clear enough.
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 account_id and search_term already documented in the input schema. The description does not add extra semantics beyond the account scope, but the baseline of 3 applies because the schema fully explains 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 uses a specific verb and resource: 'List courses under a given Canvas account.' It clearly identifies the account scope, distinguishing it from sibling tools like list_courses or list_accounts. The resource and boundary are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'under a given Canvas account' provides clear context for when to use this tool: when account-level course listing is needed. It does not explicitly exclude alternatives like list_courses or search_course_content, but the scope is evident enough for an agent to select it appropriately.
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 openWorldHint: true. The description adds value by specifying the semantic context ('when participant_type=Group') which helps the agent understand the filter. However, it does not disclose behavior regarding pagination, ordering, or what happens when participant_type is not Group. Given the annotations cover 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 a single, clear sentence that conveys the tool's purpose and a key nuance. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter, minimal description is needed. The description, combined with the schema and annotations, provides a complete picture of the tool's use case. The only area it could improve on is explaining the response data shape, but that's often unnecessary for a list endpoint.
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 (appointment_group_id) is standard and self-explanatory. The description mentions 'participant_type=Group' which implies a filter on the response but doesn't clarify how this maps to parameters beyond what's in the schema. Baseline 3 is suitable since schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is very clear with a specific verb-root and object ('List student groups'), it defines the exact resource being listed, and adds a crucial scoping detail ('that have reserved a slot in an appointment group (when participant_type=Group)'). This effectively differentiates it from sibling tools like list_appointment_group_users and list_appointment_groups.
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 clarifies when to use the tool (to list groups that have reserved a slot) and implies the alternative context by mentioning 'participant_type=Group'. However, it does not explicitly name sibling tools to differentiate from, though the context is largely clear given the unique resource. A small deduction for not being more explicit about 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?
Annotations already declare readOnlyHint: true and openWorldHint: true. The description adds moderate detail beyond this: it returns overrides targeting students/sections/groups and mentions the 422 error behavior. However, it does not elaborate on pagination, response structure, or any error conditions beyond the 422. It meets the baseline by not contradicting annotations and adds just enough context to be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences deliver the purpose, return types, and a key use case. Every sentence carries weight: the first defines, the second specifies scope, and the third explains why you'd use it. There is no redundant language, and the structure is front-loaded with the most important 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 read-only list operation with only two simple parameters, the description covers the essential aspects: what it lists, what it returns, and a practical application (auditing before creation). It does not mention pagination or response format, which could be relevant for a large dataset, but given the simplicity and the openWorldHint annotation, the description is sufficiently complete for an AI agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented as 'Canvas course ID' and 'Canvas assignment ID.' The description does not add any additional detail about parameter formats or relationships; it simply uses the context of calling overrides for an assignment. Since the schema already covers the parameters, the description correctly relies on it without duplicating information, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all due-date / availability overrides for a specific assignment in a course') which clearly identifies what the tool does. It distinguishes itself from sibling tools like 'create_assignment_override' by focusing on listing existing overrides, and it enumerates the types of overrides (students, sections, groups), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a practical use case: 'Useful for auditing before creating a new override — Canvas returns a 422 if a student-set override already exists for the same students on the same assignment.' This gives clear context for when to call this tool (before creating an override) and implies an alternative (not using it leads to errors). It lacks an explicit comparison to a specific alternative tool but effectively communicates when 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 already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral details: it explicitly says the listing is grouped by grader and assignment and filtered to dates with activity, which goes beyond the annotations and helps predict the output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and key output characteristics. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with adequate annotations and no output schema, the description is almost complete. It explains the purpose, grouping, and filtering, which is enough for an agent to understand what to expect. It could add details on ordering or pagination, but these are not essential given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers the only parameter course_id with 100% description coverage, so no additional description needed. Baseline for high schema coverage is 3; the description does not add any extra semantics beyond what the schema already provides, but that's acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists dates in a course gradebook history that contain grading activity, grouped by grader and assignment. This is a specific verb (list) and resource (dates), and it distinguishes itself from sibling tools like get_gradebook_history_day or list_gradebook_history_submissions by focusing on the day-level summary.
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 to know which days had grading activity) but does not explicitly contrast with sibling tools such as get_gradebook_history_day or list_gradebook_history_submissions. There is no guidance on when to choose this tool over alternatives, leaving it to inference.
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 is true, and the description's 'List' implies a read operation without side effects. The description adds context about what is listed (versioned submission history) beyond the annotation, which is helpful, though no additional behavioral caveats are mentioned.
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 any extraneous detail. It is well-structured 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?
Given there is no output schema, the description provides a sufficient expectation of the result (versioned submission history). It does not specify pagination or return format, but for a list operation this is acceptable. The context of gradebook history is adequately covered.
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 all four parameters (date, course_id, grader_id, assignment_id), giving 100% coverage. The tool description does not add further meaning to the parameters beyond restating the filters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (versioned submission history), and the specific filters (one grader, one assignment, specific date). This distinguishes it from sibling tools like list_gradebook_history_days, get_gradebook_history_day, and get_gradebook_history_feed.
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 indicates its own scope but does not explicitly state when to use this tool versus the other gradebook history tools. It would benefit from mentioning that it is for a targeted lookup of a specific assignment and grader on a given day, whereas other tools are for day summaries or broader feeds.
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 indicates it is a read operation, and the description 'List issues' is consistent with that. No additional behavioral context (e.g., side effects, rate limits) is provided, but the annotation covers the essential safety aspect.
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 directly states the purpose without unnecessary words or repetition. It is well-structured and easy to understand.
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 sufficiently explains what the tool does for a simple list operation. It does not mention pagination or filtering, but these are not critical for a basic listing endpoint. The absence of an output schema means no return format explanation is required, so the description is complete enough for a straightforward 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 schema provides clear descriptions for both parameters (course_id and migration_id), so the description does not need to add much. The description adds no further semantics beyond what the schema already includes, but the schema coverage is complete for the required properties.
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: listing issues from a content migration, and specifies the nature of each issue (type and description). It distinguishes itself from sibling tools by targeting migration issues specifically.
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 to view migration issues, but it does not explicitly mention when to choose this over alternatives or provide context such as prerequisites or typical scenarios. The instruction is straightforward but lacks explicit guidance on 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?
Annotations declare readOnlyHint and openWorldHint, giving the safety profile. The description adds course scoping but does not disclose pagination, ordering, or other list-specific behaviors, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no fluff. The action and scope are front-loaded and fully effective.
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 one required, well-documented parameter and readonly/open-world annotations, the description covers the essential context. It might omit edge details like pagination, but that omission is likely manageable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents course_id as 'The Canvas course ID' with 100% coverage. The description adds no extra parameter detail, but none is needed given the schema's clarity.
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 says 'List all modules in a course', with a specific verb and clear scope. It distinguishes itself from sibling tools like get_module, list_module_items, and create_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when you need all modules for a course. It does not explicitly mention alternatives or exclusions, but the scope makes the primary use case unambiguous.
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 openWorldHint=true. The description adds only the resource scope ('New Quiz (LTI)') and does not add behavioral details like pagination, rate limits, or return shape. 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 a single, front-loaded sentence with no filler. Every word adds necessary context about what the tool lists and its 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?
The tool is simple, the schema fully documents the required parameters, and the read-only annotation covers safety. The description is adequate, but because there is no output schema, some return-format or pagination detail could 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%, with both course_id and assignment_id already described. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('all items (questions) in a New Quiz (LTI)'). It distinguishes from sibling tools like get_new_quiz_item (single item) and classic quiz tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for New Quiz (LTI) items, implying it is not for classic quizzes. It stops short of explicitly naming alternatives or stating when-not-to-use, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description's 'Get' is consistent. It adds useful context about user scoping and optional group filtering, but does not describe return shape, behavior when no appointment exists, or how 'next' is determined. This is adequate given the annotations 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, front-loaded sentence with no wasted words. It communicates purpose, user scope, and optional filtering 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?
For a simple read-only lookup with one optional parameter and no nested objects, the description covers purpose, user scope, and group filtering. It does not spell out the return shape, but the tool name and 'Get' make the output inferable, and the absence of an output schema is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with 'Limit to specific appointment group IDs'. The description's 'all (or specified)' reinforces the optional array's meaning but adds no syntax or detailed format beyond the schema. 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?
The description opens with a specific verb and resource: 'Get the current user's next upcoming appointment'. It also clarifies scope ('across all (or specified) appointment groups'), which distinguishes it from sibling tools like list_appointment_groups and get_appointment_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current user's next upcoming' establishes a clear use case: fetching the authenticated user's next appointment. It does not explicitly name alternative tools or state exclusions, but the intended context is clear and distinct from appointment-group management 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 already declare the tool read-only and open-world, and the description doesn't contradict these. The description adds that the include parameter controls extra response fields but doesn't mention pagination, result limits, or behavior for missing/empty results. Given the annotations, the additional context is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences—concise, front-loaded with the primary action, and every phrase adds meaning. No fluff or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple read-only search endpoint, the description covers the essentials: what to search, which fields identify a user, and how to request additional attributes. While pagination and default return fields are not mentioned, the low complexity and presence of readOnly/openWorld annotations make the description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces search_term semantics (name, login, email) and explains the include parameter's purpose, going slightly beyond the schema's enum list to clarify the response-related intent. This adds value without redundancy.
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 'Search for users in a Canvas account by name, login, or email'—specific verb, resource, and scope. It differentiates from siblings like search_course_content and list_course_users by emphasizing account-level user search with common identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for account-scoped user searches but doesn't explicitly contrast with similar tools like list_account_users or list_course_users. There are no explicit when-to-use or when-not-to-use cues, only an implicit Search vs. list distinction.
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 set destructiveHint=true, and the description adds the valuable behavioral detail that the action is permanent, which is not fully captured by the annotation. It goes beyond the structured metadata by emphasizing irreversibility.
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 that are front-loaded with the primary action and followed by a critical caveat. Every word earns its place; no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with destructiveHint annotation and full parameter schema, the description provides the essential purpose and permanence caveat. There is no output schema to document, and no additional behavioral complexity requiring explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (course_id and topic_id) with 100% coverage. The description itself adds no parameter-specific meaning, 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 ('Delete') and resource ('discussion topic from a course'), clearly distinguishing it from sibling tools like create_discussion, update_discussion, and get_discussion. The scope is precisely stated.
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?
Usage context is implied by the clear delete action, but there is no explicit guidance on when to choose this tool over alternatives or any exclusions. For instance, it doesn't mention that this is only for discussion topics, not announcements. The permanence note indirectly warns of caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint: true, so the description's 'Get details' is consistent and adds no new safety information. It does not describe return format, error behavior, or any side effects beyond the read-only nature, which is already covered by 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 concise sentence that immediately conveys the tool's purpose. Every word earns its place, with no wasted or redundant phrasing.
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 (one parameter, no output schema, read-only annotations), the description is complete enough. It tells the agent exactly what the tool does and how to use it, and the structured fields handle the rest.
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% coverage with the parameter description 'The Canvas account ID', so the description adds no additional meaning beyond the schema. This is the baseline for high schema coverage, and no extra semantic detail is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get', names the resource 'Canvas account', and includes the scope 'by ID', making it clear that this retrieves a single account rather than listing accounts. It effectively distinguishes itself from sibling tools like list_accounts or list_sub_accounts by implying a specific lookup.
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 that this tool is for retrieving a specific account by ID, which implicitly indicates when to use it instead of listing tools. However, it does not explicitly name alternatives or give when-not-to-use guidance, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark readOnlyHint=true and openWorldHint=true, the description adds valuable context: the work flow states, URL expiry and the need to re-fetch, and the null attachment behavior. This goes beyond the annotations and helps the agent understand transient 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 concise, two sentences, with the core purpose front-loaded. It efficiently covers the essential behavior without unnecessary verbosity.
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 status-checking tool, the description fully covers the relevant behavior: the states, the download link, expiry handling, and null attachment cases. With no output schema, the description explains what to expect, making it 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.
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 (course_id and export_id) fully described in the schema. The description adds no new parameter-level information; it only mentions the export ID's source, which is already in the schema. 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 'Get the status of a content export' which specifies the verb and resource. It also distinguishes from siblings like list_content_exports (which lists exports) and create_content_export (which creates them) by focusing on a single export's 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?
Usage context is implied through the mention of 'export ID returned by create_content_export' in the schema, but the description doesn't explicitly state when to use this versus alternatives like list_content_exports. It doesn't specify preconditions or exclusions, so guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description is consistent. It adds the behavioral detail that the result includes a download URL, which is not implied by the schema or annotations, providing useful context without contradicting any flags.
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, well-structured sentence that front-loads the action ('Get metadata') and specifies scope ('single file by ID') and key output ('including download URL'). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two required parameters and no output schema, the description is complete. It states the purpose and a key output detail, and the annotations cover safety and openness. No further elaboration is needed given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both file_id and course_id fully documented in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get metadata for a single file by ID, including download URL.' It uses a specific verb ('get') and resource ('file'), and distinguishes from siblings like download_file (which likely fetches content) and list_files (which covers multiple files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving metadata of a single file but does not explicitly state when to use it over alternatives like download_file or list_files. No when-not or alternative guidance is provided, leaving the agent to infer from the name and wording.
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, which already indicates a safe read operation. The description adds the 'active' filter and 'authenticated student' scope, but does not disclose behaviors like result ordering, pagination, or potential incomplete data (despite openWorldHint). It adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It conveys 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?
With no output schema, the description should clarify what the returned courses look like (e.g., course objects with fields). It only says 'list active courses', which implies a list but gives no information about the structure or content. Given the low complexity and existing annotations, it is minimally complete but could be clearer.
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?
There are no parameters, so the description has nothing to add beyond the schema. Baseline of 4 is appropriate for zero parameters, and the description does not need to explain any input 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: listing active courses for the authenticated student. It uses a specific verb ('list') and resource ('courses'), and the scope ('authenticated student', 'active') distinguishes it from siblings like list_courses or get_course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for the authenticated student's own active courses. However, it does not mention alternatives or explicitly state when not to use this tool, which would be helpful given the many course-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds useful context by specifying that only users who reserved a slot are included. However, it does not disclose return format, pagination behavior, or permission requirements, so it adds only modest transparency 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, front-loaded sentence with no wasted words. It states the action, resource, and relevant qualifier ('who have reserved a slot') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list operation with one parameter, clear annotations, and no output schema. The description sufficiently explains what the tool returns and when to use it, making it complete for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 100% schema description coverage; the parameter 'appointment_group_id' is already described as 'The appointment group ID.' The tool description does not add further parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('participants (users) who have reserved a slot in an appointment group'). It also implicitly distinguishes itself from sibling tools like list_appointment_group_groups by specifying users rather than groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need the list of user participants for a given appointment group. It doesn't explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for a simple read-only list operation.
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 openWorldHint=true, so the description only adds the authenticated-user scope and the 'inbox messages' clarification. It does not disclose pagination, ordering, or conversation-state behavior, but for a simple read-only list tool with annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every phrase adds value: the verb, the resource definition, and the user scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool backed by clear annotations, the description is complete enough for an agent to understand when and how to invoke it. It does not need to explain return values or pagination given the tool's simplicity.
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 has zero parameters, so there is no parameter behavior for the description to clarify. Per the rubric, a zero-parameter tool receives a baseline of 4 because no semantic gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb and resource: 'List conversations (inbox messages) for the authenticated user.' It distinguishes this tool from siblings like get_conversation and send_conversation by framing it as a listing operation scoped to the user's own inbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you want the authenticated user's inbox conversations, but it does not explicitly state when to prefer it over alternatives like get_conversation or get_conversation_unread_count. The scope is clear, but no direct comparison or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include openWorldHint=true and destructiveHint=true, so the description doesn't need to restate side effects. It adds useful context about appointment groups being sign-up slots and how to structure time slots. However, it doesn't clarify what 'destructive' entails in this creation context, which would be helpful given 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?
Two sentences, front-loaded with purpose, no filler. Every clause earns its place by providing necessary usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and a non-trivial creation workflow. The description covers the essential requirements and the most important data structure (new_appointments). While it doesn't mention return values or optional settings like participant_type, the rich schema and annotations mitigate these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by mandating 'at least one' context_code (not encoded in schema) and clarifying the new_appointments structure, complementing the schema descriptions rather than merely repeating them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Create') and resource ('new appointment group (sign-up slots) in Canvas Scheduler'), immediately distinguishing it from sibling tools like update_appointment_group, delete_appointment_group, and list_appointment_groups. It is clear and not tautological.
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 guidance on required inputs ('Provide at least one context_code... and a title') and explains the format for new_appointments. While it doesn't mention alternatives or exclusion scenarios, the context is clear enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true but the description doesn't elaborate on the destructive aspect beyond implying creation. It does mention the POST key and response key difference, which is useful. However, it doesn't state side effects like whether it replaces an existing standard or if there are limitations. Given the annotation, some credit for adding request/response key nuance, but no behavioral details about side effects or irreversibility.
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 paragraph, information-dense, front-loaded with purpose, then context, then parameter semantics, then return usage. No fluff, every sentence provides unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 params, one nested object), the description covers purpose, input requirements, sorting, API key naming nuance, and how to use the returned id. It's missing some details like whether the returned object format is fully described (no output schema), but it gives enough to proceed. With annotations (openWorldHint, destructiveHint) and 100% schema coverage, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), but the description adds value: explains the value fraction meaning, sorting behavior, and the lower-bound concept. This goes beyond schema text (e.g., schema doesn't mention sorting or that lowest grade should be 0.0). Since coverage is high, baseline is 3, and this adds significant extra meaning, so 4 is justified.
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 'Create a new grading standard' with specific context (course/account), and the description adds important details like the scheme_entries format and sorting behavior, distinguishing this from sibling tools like list_grading_standards or apply_grading_standard_to_course.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use it (create) and how it relates to activation ('use that id with apply_grading_standard_to_course'), plus clarifies the mutually exclusive course_id/account_id choice and admin requirement for accounts.
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 signal mutation via destructiveHint=true, and the description adds non-obvious behavior: rate-limiting risks and the need for serial execution. It does not cover permissions or return values, but the annotation plus rate-limit context is solid.
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 with front-loaded purpose and no filler. Each sentence earns its place: what it does, what types it supports, and how to call it safely.
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 complex nested item schema and no output schema, but the description covers type support and batching guidance. It could mention return behavior or per-type requirements, but the schema handles most invocation details; a small gap around response/return value prevents a 5.
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 80%, and the schema already documents course_id, assignment_id, points_possible, position, and nested item fields. The description names the five item types but adds little beyond what the schema provides, so it meets the baseline without enriching 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 states a specific verb and resource: 'Create an item (question) in a New Quiz (LTI)' and enumerates the five supported question types. It clearly distinguishes this from sibling tools like create_new_quiz, update_new_quiz_item, and get_new_quiz_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational guidance: Canvas may rate-limit, call serially, chunk and pause for batches over 50. It does not explicitly name alternatives, but the creation scope and batching context give strong practical usage direction.
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 destructiveHint=true, and the description adds the valuable explicit detail that 'This action is permanent.' It also clarifies the LTI-specific nature of the New Quiz object and the assignment_id requirement, giving the agent context beyond the raw destructive flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the primary action, with no filler. Every sentence contributes: resource/scope, permanence, and a critical identifier caveat.
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 delete with no output schema and strong annotations, the description covers the important operational facts (permanence and assignment_id). It is complete enough for the agent to invoke correctly, though it could have explicitly named sibling alternatives for fully unambiguous selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage. The description adds meaningful clarification with 'Use assignment_id (not quiz_id),' which prevents a likely misuse when deleting New Quizzes; course_id semantics are adequately handled by 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?
Description opens with a specific action and object: 'Delete a New Quiz (LTI) from a Canvas course.' It also clarifies the correct identifier type ('Use assignment_id (not quiz_id)'), which distinguishes this deletion tool from quiz-item or classic-quiz deletion 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 clearly scopes the tool to New Quiz (LTI) objects in a Canvas course, and the assignment_id note implies this is not the normal quiz_id-based path. However, it does not explicitly name alternatives (e.g., delete_assignment for regular assignments or delete_new_quiz_item for quiz items), so when-to-use versus siblings is only implied.
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?
The description goes beyond the read-only annotation by explaining how text files are returned as readable text, binary files as base64, and that files over 10 MB are refused. These are important behavioral details not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose stated first, followed by file type handling and size limit. It is well-structured and easy to read without unnecessary verbosity.
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 functionality, return types, and size constraint. It lacks details on error cases (e.g., file not found), but for a simple download tool, this is fairly complete. No output schema exists, so the return behavior description suffices.
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 file_id and course_id. The description adds little extra meaning, mostly repeating 'by ID'. 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 that the tool downloads the content of a Canvas file by ID. It distinguishes itself from sibling tools that list or get file metadata by focusing on content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool over alternatives like get_file or list_files. It implies usage for downloading actual file content, but lacks explicit guidance or examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to repeat that. It adds useful behavioral context: grouping by display name + size, noting that Canvas lacks content hashes, and that same-name files of different sizes are not considered duplicates. This goes 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 concise and front-loaded with the core purpose. Every sentence adds value: the purpose, the rationale, the grouping logic, and the limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is complete. It explains the detection criteria, the limitation regarding content hashes, and the intended use case. The only minor gap is not describing the return format, but with no output schema and a straightforward list result, this is acceptable.
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 both parameters. The description adds context about the grouping logic but doesn't add new parameter-level 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds duplicate files in a course's Files area, specifying the criteria (same name and size) and the context (left behind by repeated course copies). It distinguishes itself from sibling tools like list_files and delete_file by focusing on detection of duplicates for cleanup.
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 this tool (to surface duplicates for cleanup) and mentions the alternative delete_file tool for the actual deletion. It doesn't explicitly state when not to use it, 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?
Beyond the readOnlyHint and openWorldHint annotations, the description adds response-related behavior: progress_url polling and workflow_state transitions. It does not mention error/failed states or polling cadence, but the annotations already establish this as a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main purpose, and then provides actionable polling guidance. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-item read with no output schema, the description covers the essential response behavior: workflow_state handling, progress_url, and completion. It could be more complete by enumerating other states such as 'failed' or specifying a polling interval, but it is sufficient for effective tool 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%, and both course_id and migration_id already have clear descriptions in the input schema. The tool description adds no parameter-level meaning, 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 and resource: 'Get the status of a single content migration.' The word 'single' clearly distinguishes this from sibling tools like list_content_migrations and list_content_exports.
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 gives clear operational context: poll progress_url when workflow_state is 'running' and treat 'completed' as terminal. It does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and mutability. The description adds the 'authenticated user' scope, which is useful, but does not elaborate on response shape or any other behavioral details. This matches the calibration example for get_calls.
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, no redundancy. Every word contributes to 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?
For a zero-parameter read-only tool with annotations, the description suffices. It clearly states what is counted and for whom. It does not specify the output format, but a count implicitly returns a numeric value; however, mentioning this would have been slightly more 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?
With zero parameters, the baseline is 4 per rubric. The description adds context by specifying the count is for the authenticated user, which clarifies the implicit scope. No further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the number of unread conversations for the authenticated user.' It clearly distinguishes itself from siblings like list_conversations (which retrieves a list) and get_conversation (a single item) by focusing on a count.
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 purpose itself makes the usage clear: use this when you only need the unread count rather than the full list. However, it doesn't explicitly mention alternatives or when not to use it, which would be a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to restate safety. It adds useful context about the single-call nature and summary stats, which helps set expectations. However, it does not disclose details about the return format, potential performance costs, or any quirks. Since annotations cover the read-only aspect, the extra context is sufficient but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and distinct value proposition. No wasted words. The structure is clear: what it does, when to use it, and why it's beneficial. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of annotations and a complete schema, the description provides enough context for an agent to understand the tool's role and when to invoke it. It doesn't explain the output format, but the summary stats and tree structure are implied. It would benefit from noting any limits (e.g., course size) but overall 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 coverage is 100%, so each parameter is already described in the schema. The description doesn't add extra meaning to parameters beyond what's in the schema, but it does imply that course_id is the key input and that include_published_only and include_content_details are optional filters. This aligns with the baseline of 3 when schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full module → items tree for a course with summary stats, using specific and concise language. It distinguishes itself from sibling tools like list_modules or list_module_items by emphasizing a single-call bulk retrieval, and from view_course_structure by hinting at a different scope (whole tree vs possibly individual module view).
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 mentions when to use it: 'when an agent needs to reason over the whole course shape' and notes the benefit of avoiding N+1 round-trips. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for an agent to infer that granular queries should use other tools. Lacks explicit exclusions but provides solid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, so the description correctly avoids repeating that. It adds the precondition that the migration must be completed, which is valuable behavioral context. 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 two concise sentences, front-loaded with the primary action and then the use case. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core purpose and precondition. Without an output schema, it does not specify the exact mapping structure, but it implies what the return is. Adequate for a straightforward get 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 both parameters completely (100% coverage) with clear descriptions. The tool description does not add any extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the old-to-new asset ID mapping for a completed migration, using a specific verb and resource. It distinguishes from siblings like get_content_migration by focusing on the mapping itself rather than migration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful context by noting it's for completed migrations and that it's useful for resolving references. However, it does not explicitly mention alternatives or when not to use it, though the context implies this is a specific post-migration lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with that by saying 'Get.' The description adds useful scope context ('currently authenticated user') but does not describe return format, profile field content, or authentication failure behavior. This is acceptable given the annotation coverage, but not especially 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, front-loaded sentence with no wasted words. It clearly communicates the action, target resource, and scope without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter, read-only tool with no output schema, the description is adequately complete. It names the resource, scope, and authentication context. It could optionally mention what profile information is returned, but this is not essential for a getter of this simplicity.
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?
There are zero parameters and schema coverage is 100%, so the schema fully describes the input surface. The description adds relevant context by clarifying that the profile belongs to the current authenticated user, which is meaningful despite the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get the profile' of the 'currently authenticated user.' It distinguishes this from sibling tools like get_user or list_accounts by specifying the self-scoped, authenticated-user 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 phrase 'currently authenticated user' gives clear context for when to use this tool: when you need the caller's own profile rather than a specific user's profile. It does not explicitly name alternatives or exclusions, but the self-scope is a strong implicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavior beyond that: it defaults to including submission_comments and explains that passing `include` adds additional data like rubric_assessment, submission_history, visibility, course, user, or read_status. This gives useful context about output behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: first states purpose, second explains the key include behavior. No filler, no repetition of schema details, and front-loaded with the primary use case.
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 single-resource fetch with all parameters documented in the schema, the description covers the essential behavioral nuances—default includes and how to expand them. It does not describe the full response shape, but no output schema exists and the annotations indicate a safe read operation, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the default behavior of `include` and that additional values expand the response. This makes parameter usage clearer than the schema alone.
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 exactly what the tool does: 'Get a single submission for a specific user on an assignment.' This clearly distinguishes it from sibling tools like list_submissions, get_submission_peer_reviews, and grade_submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need one submission for a specific user/assignment, and include optional fields. However, it does not explicitly mention when not to use it or name alternatives such as list_submissions, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds context about what appointment groups are and the meaning of the two scopes, but does not disclose return format, pagination, or default behavior when scope is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core purpose front-loaded, followed by targeted guidance for the key parameter. 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?
For a simple, read-only list operation with 3 optional parameters and full schema documentation, the description is adequate. It explains both scope options clearly. Missing details like default scope behavior and pagination would enhance completeness, but the schema and annotations carry much of the load.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds a decision-rule layer to the scope parameter ('reservable' = 'groups students can reserve', 'manageable' = 'groups the current user manages') that helps an agent choose the right intent. It does not add detail for include or context_codes, but the schema already documents those clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('appointment groups') and clarifies the domain ('Canvas Scheduler sign-up slots'). It distinguishes the tool from singular get_appointment_group and mutating create/update/delete appointment group siblings by clearly indicating this is a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the scope parameter: 'Use scope=reservable to find groups students can reserve, or scope=manageable for groups the current user manages.' This maps a user intent to each scope choice. However, it doesn't mention when to use this tool versus the singular get_appointment_group or related list 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 already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe read operation. The description adds filter guidance but doesn't discuss return behavior, pagination, or other operational aspects, keeping it at baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by high-value filter examples. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered-list tool with comprehensive annotations and full schema coverage, the description adequately covers usage. It could mention pagination or response format, but given the simplicity of the operation, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description enriches parameter meaning by explaining the purpose of combining include=grades/current_points (richer grade data), type[] (role limitation), and user_id (single user focus). This goes beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists enrollments within a specific course, with a specific verb and resource. It distinguishes from siblings like list_enrollments (which is broader) by emphasizing course-level filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit examples of when to use include, type, and user_id filters, providing clear context on usage scenarios. However, it does not name alternative tools or explicitly state when not to use this tool, falling slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the return structure (array of objects with specific fields) and the admin requirement for account_id. This goes beyond the annotation and helps the agent set expectations.
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, front-loaded with the purpose. Each sentence adds value—purpose, parameter usage, and return format. 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?
The description covers the key aspects: what it lists, the two mutually exclusive parameter paths, admin requirement, and return structure. It does not address what happens if no parameter is provided, but for a simple list tool with no output schema and good annotation coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description essentially repeats the schema's info about mutual exclusivity and admin access. It does not add new meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists grading standards, and specifies two broad contexts: course or account. It distinguishes from sibling tools like create_grading_standard and apply_grading_standard_to_course by the 'list' verb and the context parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to provide either course_id or account_id, and explains what each returns. It also notes admin access for account_id. It does not explicitly mention alternatives like creating or applying standards, but the distinction from create/apply is inherently clear from the verb 'list'.
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 critical behavioral detail beyond annotations: 'Only provided fields are changed; omitted fields are left as-is.' This clarifies partial update semantics, which annotations (destructive, idempotent, openWorld) do not specify. No contradiction with annotations; the extra context earns a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: one states the purpose, the other explains the partial update behavior. The most important information is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters but a rich schema and annotations, the description covers the essential behavioral nuance (partial update) and is sufficient. It does not describe return values, but no output schema exists and the operation is straightforward. Slight gap: no mention of prerequisites like course existence, but this is not critical for a simple update.
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 already having a clear description. The tool description adds no additional parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate since the structured data handles 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 uses a specific verb+resource structure: 'Update an existing course.' It clearly distinguishes from create_course and other course-related tools by targeting existing courses. The sentence is unambiguous about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing course through the word 'existing,' differentiating it from create_course. However, it does not explicitly mention when not to use it or name alternatives, so it lacks explicit exclusions but provides clear contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's main transparency job is to add behavior beyond those. It does that by disclosing the interactive panel behavior, the exact relationship to list_account_notifications, and the fallback payload while preserving the same JSON result. No contradiction with annotations: the tool reads and renders, it does not mutate.
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 highly informative: two sentences cover function, scope, UI behavior, sibling equivalence, and fallback handling. Every sentence contributes something useful and the primary function is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only UI-oriented wrapper with one optional parameter and no output schema, the description is complete enough. It tells the agent what kind of payload to expect by referencing list_account_notifications and discloses the fallback behavior when the MCP Apps UI is unavailable. It could go deeper, but given the annotations and simple parameter surface this is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter account_id has 100% schema description coverage, including the 'self' value and default. The description adds no further semantics about how account_id affects the interactive panel.
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 ('View') and identifies the resource: active institution-wide announcements. It also distinguishes itself from the closely named sibling list_account_notifications by stating it returns the same payload but adds an MCP Apps UI resource. This gives an agent a clear, non-tautological understanding of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly names list_account_notifications as the alternative and explains the fallback behavior for hosts without MCP Apps support, implying when this UI-oriented variant is useful. It stops short of an explicit when-not-to-use statement, such as 'if only the JSON payload is needed, use list_account_notifications,' so it misses the full explicit-when/when-not bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: the export runs asynchronously, the tool returns an ID and initial workflow_state, and the link is time-limited. It doesn't contradict annotations, and it explains the asynchronous lifecycle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, followed by the essential asynchronous behavior and a clear pointer to the polling tool. Every word is useful and no redundancy exists.
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 create operation with two parameters and no output schema, the description fully explains the workflow: start export, get ID and state, poll with get_content_export, and eventually retrieve a time-limited link. It is complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage, including the enum values for export_type and their meanings. The description only repeats the format names ('Common Cartridge / QTI / zip') without adding new semantic information, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start') and identifies the exact resource ('Canvas course content export') plus the valid formats (Common Cartridge / QTI / zip). It clearly distinguishes this from the sibling get_content_export, which is for polling progress.
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 clear context: the tool is for starting an export, and the description explicitly instructs to call get_content_export to poll progress and get the download link. It doesn't mention when to choose this over content migration tools, but the primary workflow is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is established. The description adds valuable behavioral context by detailing what the tool returns (min, max, median, quartiles, submission count, tardiness breakdown), going beyond the structured 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. The first establishes the core purpose and output, the second explains the optional parameter behavior. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description carries the burden of explaining return values and does so thoroughly: statistical summary fields, submission count, tardiness breakdown with categories. It also covers parameter scoping and reads as complete for the tool's complexity, supplemented by 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 description coverage is 100%, so the schema already fully documents both parameters. The description's guidance on assignment_id essentially mirrors the schema's own description ('Scope the result to a single assignment ID. Omit to return analytics for all assignments'), adding no new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get score distribution analytics for assignments in a course.' It lists specific outputs (statistical summary, submission count, tardiness breakdown) and distinguishes itself from sibling tools like get_course_analytics and get_student_analytics by focusing on assignment-level score distribution.
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 on when to use the tool (for assignment score analytics) and how to scope it to a specific assignment via assignment_id, with an explicit 'omit to return analytics for all assignments.' However, it does not name alternative tools or state exclusions, so it misses the explicit 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, and the description's read-only wording aligns with them. It adds the current-user scope and the returned fields, but does not disclose potential pagination, authentication requirements, or whether cards may be limited or empty, which keeps it at a moderate level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource. Every word contributes meaningful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only annotations, no nested objects), the description is complete enough for an agent to understand invocation and expected output. It specifies the key fields returned and the user scope, so no critical information appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter ambiguity and the schema already covers everything. The description adds value by naming the returned card attributes, making the output easy to infer despite no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and precise resource ('current user's dashboard course cards') and adds output details ('position, color, and image'). This clearly differentiates it from sibling tools like get_my_courses by focusing on dashboard cards rather than general course lists.
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 'current user's dashboard course cards' gives clear context that this is for the authenticated user's dashboard view, not other users or broader course listings. However, it does not explicitly name alternatives or when-not-to-use conditions, so it falls short of full 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 already declare readOnlyHint=true, so the description adds value by specifying the sort order (most recent first) and the scope (all content exports). This goes beyond the structured data, though it doesn't cover pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It succinctly conveys the action, scope, and ordering without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and no output schema, the description is complete. It covers what is returned (all exports), scope (course), and ordering, which is sufficient for an agent to decide and use 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?
The schema description for course_id ('The Canvas course ID') is generic but sufficient, and the schema coverage is 100%. The description does not add any additional parameter details, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (content exports) with scope (for a course) and ordering (most recent first). It distinguishes itself from sibling tools like get_content_export or create_content_export by its listing nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for listing all exports for a course, which implies its use case. It does not explicitly mention alternatives or when not to use it, but the context is clear enough given the sibling set.
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 (readOnlyHint: true, openWorldHint: true) already establish safety and non-exhaustiveness, lowering the description's burden. The description adds value by explaining the non-obvious term 'migrators' in parentheses and providing concrete examples of the return-value format. It doesn't mention whether types vary per course or error conditions, but for a small enumeration tool, the behavioral trace (what keys look like) is well established.
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 tight, information-dense sentences. The first states the action and scope; the second describes the output format with five illustrative examples. Zero filler words, no redundancy with the provided annotations or parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only enumeration tool with a single required course_id parameter and no output schema, the description fully covers what an agent needs: what it does, the format of the results, and representative output values. The combination of strong annotations and a descriptive component makes this complete for its complexity class.
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% (course_id is documented as 'The Canvas course ID'), so the schema already carries the parameter information. The description redundantly reinforces the 'course' context but doesn't add format, constraints, or transformation rules. Per the rubric, baseline 3 is appropriate when the schema does the heavy lifting and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb+resource construction ('List available migration types (migrators) for a course') with explicit mention that it returns migrator type keys. This clearly distinguishes it from siblings like list_content_migrations (which lists actual migration instances) and create_content_migration (which performs the migration). The examples of return values (course_copy_importer, etc.) further anchor its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strongly implies when to use this tool (to enumerate the valid 'type' keys before creating a migration or reading migration details) by explicitly listing the format of keys returned. However, it never explicitly names an alternative or provides a direct contrast, and while the return example explains the format, it doesn't mention that available migrators may vary by course, which is a natural next-step question for an agent selecting an importer.
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 declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral transparency beyond annotations by clarifying that the report is factual, not predictive, and that each finding lists the exact signals and thresholds used. This gives the agent a clear understanding of what the output will contain and how it is generated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and includes all necessary information without fluff. It efficiently explains the tool's function, the nature of the output, and permission requirements. 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?
Given the tool's moderate complexity (5 parameters, no output schema), the description is complete. It explains the overall purpose, the criteria considered, the nature of the output (factual report with signals and thresholds), and permission requirements. Since the schema covers all parameters and the description explains the expected output, the agent has sufficient information to decide when and how to use 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?
The schema has 100% documentation coverage for all parameters, so the descriptions already explain each parameter's meaning (e.g., min_late, min_missing). The tool description does not add additional parameter-level detail, but it does provide context for how these parameters work together (as thresholds for the signals). Since the schema covers parameter semantics fully, 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 the tool's purpose: it reports students who may need instructor attention based on specific criteria (inactivity, missing/late submissions, low score). It uses a specific verb ('Report') and clearly delineates the resource ('students needing attention'). This distinguishes it from sibling tools like 'list_submissions_comments_needing_attention' (which focuses on comments) and 'get_missing_submissions' (which only covers missing 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 description provides clear context on when to use this tool: when you need a comprehensive report of at-risk students based on multiple signals. It mentions required permissions ('Requires instructor/TA permissions'), which gives usage context. However, it does not explicitly name alternatives or state when NOT to use it, so it lacks explicit exclusionary guidance.
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?
The description discloses the destructive nature (delete group) and additional side effects: cancelling reservations and notifying participants via cancel_reason. This goes beyond the annotation destructiveHint:true by specifying what is affected and the notification behavior, making it fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences. It is front-loaded with the primary action and provides necessary detail without any fluff or redundancy. The structure is clear 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 simple delete operation with two parameters, the description is complete enough. It explains the main action and the effect of the optional parameter. It does not mention error handling or return values, but with no output schema and a straightforward destructive action, the description covers the essential context needed for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of cancel_reason (to notify participants), adding meaning beyond the schema's generic 'Message to include in cancellation notifications.' The appointment_group_id is self-explanatory and not further elaborated, but the description does provide useful context for the optional parameter, improving parameter understanding.
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 an appointment group and cancel existing reservations. It uses specific verbs (delete, cancel) and specifies the resource (appointment group), distinguishing it from other appointment group tools like get, create, update, and 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 does not explicitly state when to use this tool versus alternatives. The usage is implied: you use it to delete an appointment group. It does not mention conditions or exclusions, but the action itself is straightforward. The optional cancel_reason for notifications is noted, but no guidance on when to provide it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context by stating defaults (term, total_students) and that the include parameter replaces (not augments) the default set. This goes beyond the annotations without contradicting them, though it does not describe response structure or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, followed by the default behavior and the key parameter behavior. No filler words; 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?
For a read-only tool with all parameters documented in the schema and no output schema, the description covers the essential behaviors: what it does, what is returned by default, and how to customize. The teacher_limit parameter is adequately described in the schema, and the description's focus on include semantics fills the most nuanced gap. Overall, the tool is fully characterized for an agent to select and invoke correctly.
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 schema already documents all 3 parameters, but the description adds key semantics: it reveals that `term` and `total_students` are requested by default and that `include` replaces this default set, which is not evident from the schema alone. This meaningfully helps the agent use the include parameter correctly, especially with the enum list provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get details for a single course,' a specific verb+resource that clearly differentiates from siblings like list_courses and get_course_analytics. It also clarifies the single-course scope, which is further reinforced by the required course_id parameter in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it operates on a single known course (implied by 'single course') and explains the default include set and how to replace it, but it does not explicitly specify when to use this tool over alternatives like list_courses or get_course_analytics. Thus usage guidance is implied rather than explicit, with no clear exclusions or named alternatives.
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 declare readOnlyHint and openWorldHint, but the description adds substantial behavioral detail beyond those: self-comments are excluded, submissions with no non-self comments are omitted, failing courses are reported in courses_failed, results are sorted most-recent-feedback-first, and teacher/peer role labeling is best-effort with a specific rule. 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?
Four sentences, each carrying distinct information: core filtering rule, cross-course scanning with error handling, sort order, and role-labeling limitation. There is no redundant or filler content, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description covers the essential behavior: filtering semantics, cross-course error handling, sorting, and role labeling limitations. It does not specify the exact shape of returned submission items or pagination, but the information provided is sufficient for an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage), so the description adds little parameter-specific meaning. It reiterates the course_id omission behavior already in the schema and does not introduce new details for unread_only beyond the schema's existing 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 opens with a specific verb and resource: 'List the authenticated student's own submissions that carry feedback comments from an instructor or a peer reviewer.' It clearly differentiates this tool from siblings like get_my_submissions by focusing only on submissions with non-self feedback and explicitly excluding self-comments.
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 clear context for when to use the tool: omit course_id to scan all active courses, use unread_only to filter unopened submissions, and understand that per-course errors are skipped. However, it does not explicitly name alternative tools or state when not to use this tool, 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 readOnlyHint and openWorldHint annotations already signal safety. The description adds behavioral clarity by explaining how include parameters transform the response shape (nesting assignments) and affect scope. It doesn't discuss pagination or default behavior, but for a read-only list with strong annotations, 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?
Two sentences, both packed with actionable information. The first defines the resource, the second explains the include parameter with an explicit example. No fluff, perfectly sized.
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 high schema coverage and readOnly annotation, the description covers the core semantics (what the tool returns, how to get nested assignments, how to augment with other includes). It misses explicit mention of filter parameters like grading_period_id or scope_assignments_to_student, but the 100% schema coverage and simplicity of the list operation make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by paraphrasing the key includes and their semantic effect (nesting assignments, adding metadata). The explanation of 'etc.' plus specific JSON-like example demonstrates practical usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists assignment groups (categories) in a course, using specific verb+resource language. It distinguishes itself from sibling tools like list_assignments by framing groups as categories with nested assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong guidance on how to use the tool, especially include=assignments for nesting and other includes like submission, overrides, and score_statistics. It does not explicitly state when NOT to use it or name alternative tools, but the usage context is clear enough from the given detail.
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 and openWorldHint. The description adds valuable behavior: what slim returns, what full includes, and how include extras work. It does not cover pagination or full return shape, but given the read-only safety profile, this is acceptable and adds context beyond 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 sentences, highly information-dense, no filler. Key guidance (slim vs full) is front-loaded, followed by bucket and other filters. 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 complex tool with 10 parameters and no output schema, the description covers essential usage patterns (slim selection, full detail, filtering). It lacks explicit mention of pagination or default ordering, but the guidance is sufficient for an agent to invoke correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the purpose of fields="slim" vs 'full', the role of bucket, and how include relates to full mode, which enriches parameter understanding beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all assignments in a course') and clearly distinguishes from siblings like get_assignment by focusing on listing. It also explains the projection modes (slim vs full), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: use fields="slim" for enumerating assignments and switch to "full" once the target is identified, plus guidance on bucket filtering. It lacks direct mention of alternative tools or exclusions, but the context is clear enough for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by detailing behavior of fields: slim returns only a subset, full includes all fields and include extras. It also clarifies that include is ignored when slim. This goes beyond annotations 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?
Concise, well-structured description with front-loaded purpose. Each sentence adds value: purpose, usage scenario, field projections, and filtering semantics. 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 5-parameter schema with enums and the absence of an output schema, the description covers purpose, parameter use, and interplay thoroughly. It omits pagination details, but for a list tool this is often implicit. The description is complete enough for correct 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 covers all parameters, so baseline is 3. The description adds meaningful semantics: explains the trade-off between slim and full, the effect of include (ignored in slim), and the meaning of state vs enrollment_state. This enriches the agent's understanding of how to combine parameters effectively.
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?
Clear action verb and resource: 'List courses for the authenticated user' distinguishes from account-level listing. It also specifies the scope (authenticated user) and parameter roles, making it distinct from sibling tools like get_my_courses or list_account_courses.
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 usage guidance for fields parameter: 'Use fields="slim" when enumerating... switch to "full" once you have identified the target.' Also explains state and enrollment_state filters. Does not mention alternatives or exclusions, but the guidance is actionable and 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 declare readOnlyHint=true. Description adds useful behavioral context such as the fact that include requests fields 'otherwise omitted from the default response' and filters narrow by role/status. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences convey the tool's purpose and all parameter roles without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list endpoint with 8 parameters and no output schema, the description covers all parameters and their effects. It lacks explicit pagination/response format details, but annotations and schema coverage make this sufficient.
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. Description adds value by grouping parameters into meaningful intents (role/status, name/login, specific subset, ordering) and clarifying default-response behavior for include.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb and resource: 'List users in a course'. It clearly differentiates from account-level or student-only tools by stating course scope and optional Canvas filters.
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 clear context for when to use (course roster with filters) and thoroughly explains each filtering option. Does not explicitly name alternatives like list_account_users or list_students, so loses the top score.
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 significant behavioral details: it reads from submission records because Canvas exposes no direct read endpoint, makes one API call per Classic Quiz, may be slow for many quizzes, and propagates errors immediately without per-quiz catching. These details are valuable for an agent predicting latency, failure modes, and side effects. 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 composed of six tightly packed sentences, each serving a distinct purpose: what it lists, when to use it, what it excludes, how it reads, performance/error characteristics, and the pseudonym prerequisite. No filler or redundant elaboration; information is front-loaded with the core action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the essential dimensions: scope, exclusions, implementation method, performance, error behavior, and a preprocessing requirement. It does not explicitly state the return shape (e.g., a list of quiz IDs with extra_time/extra_attempts), but the opening line and the reading mechanism imply it. For a read-only list tool with this complexity, the description is nearly complete, with only a small gap around response format.
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 (course_id and user_id) with clear descriptions, and the schema description coverage is 100%. The description's phrase 'Provide user_id as the real Canvas user ID' reinforces the schema but adds little beyond it. Since the schema carries the semantic load, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List the current quiz accommodation (extra time and/or extra attempts) for a specific student across all Classic Quizzes in a course,' using a specific verb, resource, and scope. It explicitly excludes New Quizzes, distinguishing it from list_student_new_quiz_accommodations and matching its title. This is a model of clear 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 states 'Useful for auditing before or after calling set_student_quiz_accommodation,' which gives actionable context for when to invoke it. It also provides a prerequisite for pseudonymized environments ('If CANVAS_PSEUDONYMIZE_STUDENTS is enabled, call resolve_pseudonym first') and notes the New Quizzes exclusion. It does not explicitly name alternative tools for New Quizzes, but the contrast with set_student_quiz_accommodation and the exclusion phrase make intended usage 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?
Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description discloses meaningful behavioral traits: the permission requirement (instructor/TA only) and the deterministic result ordering ('oldest-unaddressed first'). The plain-language gloss 'comments the instructor has likely not seen' adds interpretive value. However, it doesn't disclose potential full-course scan behavior when assignment_ids is omitted, nor does it address pagination or result limits for what could be a large triage 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?
Three tight sentences with the purpose front-loaded: the first sentence states the core filter, the second describes return shape and ordering, and the third covers permissions. There's no fluff, and the em-dash gloss ('i.e. comments the instructor has likely not seen') serves a clarifying role rather than being redundant. 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 there's no output schema, the description compensates reasonably well by specifying the return shape ('Returns a triage list') and its ordering, plus the permission precondition — combined with openWorldHint annotation, this covers the agent's needs for decision-making reasonably well. It could go further by noting the scale/performance implications of fetching all assignments when assignment_ids is omitted, and by clarifying whether the returned items are submissions, comments, or both.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is already 3; the description elevates this by clarifying the default/course_id-only invocation behavior (the base triage filter described in prose maps to the unfiltered call, plus ordering semantics). The description doesn't add per-parameter syntax but effectively frames what the base query returns so that unread_only and assignment_ids can be understood as refinements on the triage query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction ('List submissions where the most recent comment is from the student...') and precisely defines the otherwise-vague 'needing attention' with concrete criteria (most recent comment from student, unaddressed by grading or reply). It distinguishes itself from near-siblings like list_students_needing_attention and list_submissions_awaiting_grading by focusing on comment-thread state rather than grading state, and the 'oldest-unaddressed first' detail clarifies the triage semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear when-to-use context: it identifies the exact filtering scenario (unaddressed student comments the instructor likely hasn't seen) and the permission precondition ('Requires instructor/TA permissions in the course'). However, it doesn't explicitly name alternative tools or state 'use X instead for Y' — the differentiation from sisters like list_submissions_awaiting_grading or list_students_needing_attention is implied through semantics rather than stated as 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?
Given that readOnlyHint and openWorldHint are true, the description adds context by noting the default behavior of including 'submission_comments', which isn't captured elsewhere. It does not introduce contradictions. The description adds context about the 'include' default and mentions the possibility of filtering, which is behaviorally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary purpose, and packs in useful parameters and default behavior without fluff. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only, open-world annotations, the description covers the primary use case, filter options, and default includes. It could potentially mention pagination or ordering, but those may not be necessary. The tool has no output schema, so return-value details might be helpful, but the description is complete for the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema (100% coverage), so the description doesn't need to re-explain them. The description does mention filters, but the schema already provides clear descriptions. Since the schema covers 100% of parameters, the baseline is 3. The description doesn't add extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all submissions for an assignment') and differs from siblings like get_submission (which retrieves a single submission), and related functions like list_submission_comments_needing_attention. It is distinct from the broader 'list_assignments' or 'get_my_submissions' 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 explicitly mentions using 'include' to attach related objects and filtering with 'student_ids', 'workflow_state', or 'grading_period_id'. This gives clear context on when to use the tool and what parameters are relevant. It could more strongly note when not to use it, but for a likely common tool, alternatives are somewhat addressed. The description could be stronger with explicit exclusions, but the presence of parameters and the note about 'Defaults to...' establishes clear usage context.
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?
The annotations already indicate a safe read-only operation, but the description adds rich behavioral context: exactly what gets surfaced, what does not (New Quizzes pending_review, fill-in-the-blank), the submission-level-only limitation, pseudonymization behavior, and the version-specific caveat. There is no contradiction with the annotations; everything aligns with readOnlyHint=true.
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 well-structured and front-loaded with the core outcome, then moved into return-shape, parameters, and known limitations, which makes it easy to navigate. It is longer than the strict minimum because the Parameters section duplicates schema content, but the known-limitations list adds enough standalone value to justify most of its length.
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 still fully explains the return shape (triage list grouped by assignment or quiz, with student identity, workflow state, submitted_at, and pending manual-grading flag), sorting, filter scenario categories, and edge cases such as New Quizzes, fill-in-the-blank, and pseudonymized students. This is a very complete specification for an ungrading-queue viewer.
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 has 100% description coverage, so the parameter meaning is available without relying on the tool description. The description adds the Parameters section, but it mostly restates the schema semantics for combine, assignment_ids, include_quizzes, include_assignments, and only_pending_review. Therefore it stays at the baseline: no harm, but no significant additional parameter knowledge.
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-plus-resource statement: 'Lists all submissions in a course that still need a human grade, sorted oldest-waiting first.' It clearly distinguishes this from generic list tools by enumerating the two workflow states, submitted and pending_review, and explains the triage grouping.
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 conveys clear usage context for grading triage and explicitly tells the agent when not to rely on it (e.g., New Quizzes may not show pending_review here; use SpeedGrader or the New Quizzes interface). It also directs the agent to resolve_pseudonym for pseudonymized student identities. It does not explicitly name sibling MCP tools such as list_submissions as alternatives for general submission listing, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds transparency beyond the destructiveHint annotation by explicitly stating that 'delete' is permanent while 'conclude' and 'deactivate' are reversible. This discloses the key behavioral difference between the operations. It does not contradict annotations, and it provides useful context about the consequences of each task.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two clear sentences. It avoids unnecessary detail and gets straight to the point, providing essential information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation, the description adequately covers the permanence aspect. It does not mention side effects or prerequisites, but for a simple removal tool, it provides enough context. The absence of an output schema makes it acceptable that no return values are described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes each parameter, and the description adds value by elaborating on the 'task' parameter, explaining that delete is permanent and others are reversible. This clarifies the meaning of the enum values. For course_id and enrollment_id, the schema descriptions suffice, so the additional context is minimal but beneficial.
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: removing or concluding an enrollment from a course. It specifies the action (remove/conclude) and the resource (enrollment) in context, and distinguishes between delete (permanent) and conclude/deactivate (reversible), making it distinct from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by differentiating the three task types (delete vs. conclude vs. deactivate) and their reversibility. While it does not explicitly mention alternatives, it is the only enrollment removal tool among siblings, making its purpose clear enough. The note about permanence helps users choose the appropriate task.
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 openWorldHint=true, indicating a mutating operation. The description adds context beyond annotations by explaining the purpose of key parameters like publish (making a draft visible) and new_appointments (adding time slots). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose ('Update an existing appointment group'), followed by concise, actionable guidance on key parameters. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and annotations, the description is adequately complete. It covers the essential mutation behavior and highlights the most important optional parameters. It does not mention return values or output, but no output schema exists and that is not a requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all 8 parameters. The tool description adds semantic value by clarifying the effect of publish (making a draft visible) and new_appointments (adding time slots), which goes beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update an existing appointment group.' This uses a specific verb and resource, and it distinguishes itself from sibling tools like create_appointment_group, get_appointment_group, and delete_appointment_group by making the update operation explicit.
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 on how to use the tool, such as 'Use publish=true to make a draft group visible to participants, or add new time slots via new_appointments.' It gives concrete usage examples but does not explicitly contrast with alternative tools (e.g., 'use create_appointment_group for new groups'), though that is implied.
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 include destructiveHint: true, and the description aligns by stating 'Update an existing calendar event'. It adds the behavioral nuance of partial updates ('Only provided fields are changed'), which is not captured in annotations. This adds value beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero redundant words. The key information ('Update an existing calendar event' and 'Only provided fields are changed') is front-loaded and immediately actionable.
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 update tool with good schema coverage and annotations, the description is adequate. It covers the core behavior (partial update) and references existing events, but does not mention potential errors (e.g., non-existent event ID) or any validation constraints. However, these are less critical for a simple mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for each parameter. The description reinforces that parameters beyond the required event_id are optional and only applied if provided, which is a crucial semantic not fully explicit in the schema. This adds meaning beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing calendar event') and specifies the resource (calendar event). It distinguishes from siblings like create_calendar_event by focusing on existing events. The phrase 'Only provided fields are changed' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear guideline: only provided fields are changed, implying partial update semantics. It does not explicitly mention alternatives or when not to use, but the context of 'existing' implies this is for updates, not creation. It could be improved by explicitly referencing create_calendar_event for new events.
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 idempotent and destructive hints. The description adds valuable context about rate limiting and suggested batching, which goes beyond structured metadata. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Front-loaded with the core purpose, followed by actionable usage notes. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex item schema, the description focuses on operational aspects (serial calls, batching) that are not covered by schema or annotations. It could mention that different interaction types have different required fields, but that's already in the schema. No output schema exists, but the description doesn't need to explain returns.
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 83%, so parameters are largely documented. The description adds the crucial insight that all fields are optional and only changed fields need to be supplied, which is not explicit in the schema for partial updates.
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 updates an existing item (question) in a New Quiz, using a specific verb and resource. Distinguishes from siblings like create_new_quiz_item, delete_new_quiz_item, and get_new_quiz_item by focusing on modification.
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?
Gives explicit guidance on serial calls, chunking for >50 items, and handling rate limits. While it doesn't explicitly contrast with alternatives, the context and purpose make usage 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 declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds value by disclosing the fallback behavior for hosts without MCP Apps support and the additional UI resource linkage, which are behavioral traits not captured by annotations. It doesn't describe return format details, but given the annotations and the explicit reference to get_course_structure's payload, this 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 two sentences, front-loaded with the core purpose, and every sentence adds value: the first states the primary function, the second explains the fallback behavior and relationship to get_course_structure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema), the description is complete enough: it explains the interactive UI feature, the fallback, and the relationship to a sibling tool. It doesn't detail the JSON payload structure, but since it explicitly says it's the same as get_course_structure, that reference covers completeness. The annotations provide safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (course_id, include_published_only, include_content_details) with descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an interactive tree view of a course's modules and items, and explicitly distinguishes it from the sibling tool get_course_structure by noting it returns the same payload plus an MCP Apps UI resource. The verb 'view' and resource 'course structure' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: when an interactive tree view is desired, and notes that hosts without MCP Apps support fall back to the JSON payload, which is the same as get_course_structure. This provides clear context and implicitly contrasts with the alternative get_course_structure, which is a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description adds meaningful behavioral detail: applying a standard makes the gradebook use it, and passing null removes the current standard. It also discloses the return value ('Returns the updated course object'), which supplements the annotations even if it doesn't elaborate on permissions or broader side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and each one earns its place: what the tool does, how to supply the ID, and the special null behavior plus return value. It is front-loaded with the core purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool, the description covers the operation, parameter sourcing, removal behavior, and return type. With no output schema, it appropriately states that an updated course object is returned. The combination of annotations, schema, and description is sufficient for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra value by telling the agent that grading_standard_id should come from create_grading_standard or list_grading_standards, and it reinforces the null-removal semantics already present in the schema. This goes slightly beyond the schema's bare parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply an existing grading standard to a course'), the specific resource, and the intended effect ('so the gradebook uses it'). It also distinguishes itself from related tools like create_grading_standard and list_grading_standards by focusing on application/removal rather than creation/listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool, including how to obtain the grading_standard_id and that passing null removes the standard. It does not explicitly state when not to use this tool or list alternatives, but the context is strong enough for an agent to distinguish it from create/list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds valuable behavior beyond this: it is 'factual,' returns findings 'grouped by check,' and explicitly excludes student submission data. It also states the permission requirement, which is not in annotations. However, it does not describe exact output shape or rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first lists the checks and states the report's purpose, the second clarifies scope and gives alternatives. No redundant wording, front-loaded with the main action. 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?
For a read-only report tool with no output schema, the description gives a clear picture: what problems it finds, that it returns findings grouped by check with plain-language details, what it does not cover, and permission requirements. This is complete context for an agent to select and invoke 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%, so the schema already documents both parameters well. The description lists the specific check names in its prose, which helps a user understand what the 'checks' parameter values mean, but it doesn't add syntax or format details beyond the 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 uses a specific verb ('Run') and resource ('course-readiness report') and enumerates exactly what configuration problems it surfaces (missing due dates, unpublished items, etc.). This clearly distinguishes it from sibling tools like health_check and list_students_needing_attention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('config-health report') and when not to use ('does not inspect student submissions or performance') by naming alternatives (list_students_needing_attention / get_missing_submissions). Also notes the permission requirement ('instructor permissions'), which is practical 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 already provide openWorldHint and destructiveHint; the description enriches this with the 422 conflict behavior, the omit-a-date-to-leave-unchanged semantics, and the pseudonym gotcha. However, given destructiveHint is true, it would be helpful to explain what makes this destructive, and no contradiction exists, just a modest gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At roughly 110 words across 6 sentences, the description is dense but every sentence earns its place, covering purpose, constraints, error behavior, and a configuration caveat. It's effectively front-loaded with the core purpose and would only be slightly improved by trimming.
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 complex 9-parameter tool with no output schema, the description covers the critical ground: target selection, date constraints, format, an error case, and an environment-conditional prerequisite. Minor gaps remain — return behavior is unspecified (no output schema note) and the destructiveHint flagged in annotations is unaddressed.
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?
User-schema description coverage is 100%, so the baseline is 3. The description adds meaningful cross-parameter constraints not in the schema: the exact-one-target and at-least-one-date rules, the ISO 8601 format with example, and the 'omit to leave unchanged' date semantics. This goes beyond what the schema states.
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 first sentence, 'Create a due-date / availability override for a specific assignment, targeting a set of students, a course section, or a group,' uses a specific verb+resource and clearly scopes the target types. This distinguishes it from nearby siblings like list_assignment_overrides and set_student_assignment_dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage rules: mutual exclusivity ('Exactly one of student_ids, course_section_id, or group_id must be provided'), the required date-field constraint, an explicit alternative ('use list_assignment_overrides to audit first'), and a conditional prerequisite ('If CANVAS_PSEUDONYMIZE_STUDENTS is enabled, call resolve_pseudonym first'). This is exemplary when-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 description discloses asynchronous behavior: the tool returns immediately with a migration ID and a progress_url, and explicitly directs polling get_content_migration or progress_url for completion. The annotations include openWorldHint=true, meaning the operation may have side effects outside the system. The description notes the user can select content for selective import via get_migration_selective_data when selective_import is true, adding important behavioral context. However, it doesn't explicitly address that the operation is long-running or potentially destructive—although the destructiveHint=true annotation is consistent with a function that copies data into a course, so there's no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main verb and resource. The first sentence lists specific migration types, the second explains asynchronous behavior, and the third tells the agent exactly what to do next—check get_content_migration or progress_url. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no explicit output schema, the description explains the asynchronous return (migration ID and progress_url), tells how to track completion (poll get_content_migration or progress_url), and mentions the selective import flow (get_migration_selective_data). It also packages the key mental model of destination course_id. The description makes the tool fully usable without additional lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description doesn't need to repeat parameter details. However, the description makes an important semantic clarification that the tool initiates a migration, frames the course_id as the destination course, and explicitly mentions 'poll get_content_migration or progress_url to track completion,' connecting the returned ID to the broader workflow. While the description doesn't add function-call details for each parameter, it clarifies the asynchronous 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 title and description clearly state the tool starts a content migration with a specific verb. The description says 'Start a content migration' and lists the migration types (course copy, Common Cartridge import, zip import, QTI conversion, or Moodle conversion), which uniquely identifies this tool even among migration-adjacent siblings like create_content_export and list_content_migrations. The phrase 'course copy' in the description maps to the sibling get_content_migration, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is an asynchronous action ('Migrations are asynchronous — this tool returns immediately with a migration ID and progress_url'), which guides the agent on expected behavior. It also names the related tool get_content_migration for tracking completion. However, there is no explicit 'when not to use' guidance contrasting it with alternatives like create_content_export or upload_file, though the clear subject matter partially covers this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds valuable behavioral context: it returns sections depending on permissions, includes a caveat for students, and provides a shareable summary paragraph. This goes beyond the annotations by explaining what different users see and the permission dependency, making it highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for each policy area and a concluding note about alternatives and permissions. It is concise—no redundant sentences—and front-loaded with the main purpose. Every sentence adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool explains multiple aspects of grading policy, and the description covers all major return sections (missing/late policies, weights, scheme) as well as the summary paragraph. Since there is no output schema, the description effectively replaces that by outlining what the agent can expect. Permission differences and alternative tool are also covered, making it complete for a tool of 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 only parameter, course_id, is fully described in the schema ('Canvas course ID to explain the grading policy for'). Schema coverage is 100%, so per the rubric the baseline is 3. The description does not add additional parameter semantics, but the schema is sufficient; no further clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool 'Explains the grading automation rules configured for a Canvas course' and enumerates specific aspects (missing-submission, late-submission, group weighting, grading scheme). It distinguishes itself from sibling explain_grade by explicitly mentioning that compute actual weighted grade is a different tool, so the purpose 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note explicitly says 'Use explain_grade to compute the actual weighted grade for a specific student,' providing a direct alternative. It also explains permission requirements (instructor/admin for late/missing policy, students get limited sections), giving clear guidance on when and for whom this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable context: the treatment of 404 as 'no record' (returning has_accommodation: false), the single course-level record nature, and the pseudonym caveat. This goes beyond what annotations convey, though it could also comment on response structure beyond the single field.
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 multi-sentence but each sentence carries distinct, necessary information (purpose, error behavior, scope, alternative tool, parameter caveat). It is well-structured, with the core purpose first, followed by operational details. Slightly longer than minimal but no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately explains the key return behavior (has_accommodation flag) and the 404 handling. It also clarifies the course-level scope, which is critical for correct interpretation. It could have also mentioned any potential pagination or rate limits, but these are minor gaps.
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 already provides clear descriptions for both parameters (real Canvas user ID, course ID). The description enhances this by specifying that user_id must be the real (non-pseudonymized) ID and advising to call resolve_pseudonym first if needed. This adds meaning beyond the schema's basic labels.
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 reads New Quizzes accommodations for a specific student, with specific fields (time multiplier, extra attempts). It distinguishes from the Classic Quiz variant by explicitly naming the alternative, and from the setter tool. The scope is precise and immediately comprehensible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: for auditing before/after set_student_new_quiz_accommodation, and explicitly points to list_student_quiz_accommodations for Classic Quizzes. Also mentions the prerequisite of resolving pseudonyms if needed, which clarifies when additional steps are required.
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?
Goes well beyond the readOnlyHint/destructiveHint annotations by disclosing the uniform-x model, frozen drop rules, unsupported late penalties, per-student limitation, and pseudonym resolution requirement. This gives the agent a strong understanding of the tool's edge cases and 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 well-structured with a lead summary, a Returns section, and a Limitations section. It is appropriately detailed for the tool's complexity and contains no redundant or filler sentences.
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?
Even without an output schema, the description fully enumerates return values, feasibility states, per-group breakdown, and plain-language output. It also covers key constraints and environmental considerations, making it complete for a complex projection 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 the schema already documents all four parameters well. The description adds minor context such as the exclusivity of target types and pseudonym handling, but it does not significantly extend the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Projects the minimum score needed on remaining assignments to reach a target course grade.' It clearly differentiates this computation tool from sibling tools like explain_grade and explain_grading_policy by focusing on projection rather than explanation.
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 clear invocation context: when to use it, how targets work, and how to handle student_id including pseudonym resolution. However, it does not explicitly mention alternatives or state when NOT to use this tool versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable context: the 'needs_manual_grading' field for certain question types, the per-submission API call behavior with partial failure handling (submissions_failed), and pseudonymization under a config flag. These details go beyond the annotations, enhancing the agent's understanding of output and edge cases. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 160 words, which is longer than the terse example but every sentence adds meaningful information. It is front-loaded with the main purpose and then details usage constraints and behavioral nuances. It could be slightly trimmed, but overall it is efficient and 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?
With no output schema, the description compensates by describing key output fields (needs_manual_grading, points_possible), error handling, and environmental behavior (pseudonymization). Combined with the rich annotations and schema, it provides a complete picture for safe invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains question_id's optional nature and filtering behavior. The description reiterates this but adds no new semantic details beyond what the schema provides. Thus, 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 purpose: to review student answers to quiz questions, pivoted by question, for Classic Quizzes. It explicitly differentiates from alternatives like SpeedGrader and mentions the specific quiz types it supports, making the purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: for grading essay/short-answer/file-upload questions across a class, and when-not-to-use: New Quizzes (different API). It also clarifies the optional question_id parameter's role in scoping, which guides correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses default behaviors (end_date defaults to start_date, start_date defaults to today, type defaults to 'event') and the unbounded nature, which is more than annotations alone provide. No contradiction with annotations (readOnlyHint=true, openWorldHint=true). Could add a note about response format, but not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by exclusions and default behavior. Every sentence serves a purpose with no redundancy. Exceptionally concise for the amount of information conveyed.
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 params, one enum, no output schema), the description covers essential usage and defaults. It doesn't detail return structure, but that's not necessary without an output 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters (100% coverage), so baseline is 3. The description adds meaningful defaults and usage for end_date, start_date, and type, enhancing understanding beyond the schema. This extra context justifies a score of 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 lists calendar events for a course, with a specific verb and resource. It explicitly differentiates from siblings by noting the caps on `get_upcoming_events` and `get_my_upcoming_assignments`, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it explains when to use this tool (when you need more than the ~1-week/20-item caps) and how to extend the default single-day range by passing both start_date and end_date. It also mentions the type parameter for assignment due dates, giving clear directional 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 openWorldHint=true, and the description aligns with these (scanning is read-only, and the tool is open-world in that it doesn't cover everything). The description adds valuable context beyond annotations: it explains the tool's limitations (structural checks only, no color contrast), the severity levels (error vs advisory), and the opt-in behavior for quizzes. It doesn't describe the exact output format, but the absence of an output schema and the rich detail provided justify a 4 rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the core purpose, then details the specific checks, limitations, opt-in behavior, and relationship to alternatives. Every sentence adds meaningful information without redundancy. It's longer than the TDQS 4.3 example but appropriately so given the tool's complexity.
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 (multiple content types, multiple issue categories, opt-in parameter, limitations, and relationship to an alternative), the description is remarkably complete. It covers what the tool does, what it doesn't do, when to use it, and what permissions are needed. The absence of an output schema is compensated by the description's clarity about the types of findings (WCAG criterion + severity).
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 schema). The description adds value by explaining the default behavior (omitting 'include' scans the default four sources) and the opt-in nature of 'quizzes', which goes beyond the schema's enum listing. However, the description doesn't add much about 'course_id' beyond what the schema provides, so a 4 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 scans course content for WCAG 2.1 accessibility issues, listing specific content types and specific problem categories. It distinguishes itself from the sibling audit_course_links by focusing on accessibility rather than links, and from Canvas's in-app checker by noting it complements rather than replaces it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to scan for structural accessibility issues), what it does not do (no color-contrast checking, no list-misuse detection), and how it relates to alternatives (complements Canvas's in-app Accessibility Checker). It also specifies the opt-in 'quizzes' parameter and the permission requirement (instructor permissions).
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 openWorldHint=true, and the description adds valuable context: it performs structural checks only (no outbound HTTP requests), requires instructor permissions, and explains that quizzes are opt-in due to extra API calls. It doesn't contradict annotations and adds behavioral details 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?
The description is well-structured and front-loaded with the core purpose, then details the optional quizzes behavior, and ends with constraints. Every sentence adds value without redundancy, 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.
Completeness5/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 (2 params, no output schema), the description is complete: it covers what is scanned, the optional quizzes behavior, the nature of findings (cross-course references, empty/malformed URLs), constraints (no HTTP requests, permissions), and the rationale for opt-in quizzes. No gaps remain for an agent to misuse it.
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 detailed descriptions for both parameters. The description adds meaning by explaining the default behavior (four content types) and the implications of including quizzes (extra API calls, silent breakage for students). This goes beyond the schema's basic enum listing.
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 scans a course's content for broken or outdated links and images, listing specific content types and the optional quizzes inclusion. It distinguishes itself from siblings like audit_course_accessibility and check_course_setup by focusing on link integrity and structural checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool (to find broken links, especially cross-course references after imports) and when not to (no outbound HTTP requests, structural checks only). It also notes the opt-in nature of quizzes and the permission requirement, providing clear context for selection.
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?
The description adds substantial behavioral context beyond the readOnlyHint/openWorldHint annotations: it discloses that Canvas REST API does not expose curves/fudge points, that a caveat is added for discrepancies over 0.5 pp, that only one student is computed per call, and that reconciliation is against the cross-period grade under grading periods. This goes well beyond the structured 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 structured with a dense first sentence followed by a focused limitations list. Every sentence adds relevant information—calculation details, use case, student constraint, API limitation, grading-period handling, and pseudonym prerequisite. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly conveys what the tool computes and what caveats apply. It covers the calculation inputs, the reconciliation behavior, limitations due to API gaps, grading periods, and pseudonymization. This is sufficient for an agent to decide when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds useful extra semantics: 'V1 computes one student per call' clarifies the student_id limitation, and the pseudonym-resolution note adds operational behavior around the parameter. The assignment_group_id narrowing behavior is already fully described in the schema, so the description's additional value is moderate but meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Recomputes and explains the weighted course grade for a student.' It enumerates the exact outputs (assignment-group weights, drop rules, per-group breakdowns, letter grade, reconciliation check), clearly distinguishing this from generic grading or policy tools like project_grade and explain_grading_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use this when you need to verify that Canvas's displayed grade matches the rules, or to explain to a student or instructor how their grade was calculated.' It also provides important prerequisites and limitations (one student per call, pseudonym resolution, grading-period caveat), though it does not explicitly name alternatives or say 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavioral context: event types, chronological ordering, single-submission scoping, access permissions, and the integrity caveat. There is 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 four sentences, front-loaded with the core purpose, and every sentence adds distinct value: event types, use case, Classic-only limitation, permissions, and a usage caveat. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description sufficiently explains what the tool returns (chronological event log with named event types), its scope, permissions, and limitations. Given the moderate complexity and strong annotations, this is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description does not add significant parameter-level detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('event log for a Classic Quiz submission'), lists concrete event types, and clarifies chronological ordering. It distinguishes itself from sibling tools like get_quiz_submission_answers and list_quiz_submissions by focusing on the event timeline rather than answers or submission lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use this to understand the timeline of a student's attempt'), when not to use it ('Classic Quizzes only — New Quizzes does not expose event logs via the Canvas REST API'), and provides a strong caution against using event logs as the sole basis for academic-integrity conclusions. This is clear usage guidance with exclusions.
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 and openWorldHint annotations, the description reveals crucial behavior: results are capped by max_files, truncated signals a shortened result set, URLs are time-limited, and pseudonymization behavior changes user_name but not user_id. These details materially affect how the agent interprets results.
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 longer than a simple two-sentence tool, but every sentence adds a distinct operational constraint or clarification (bounding, truncation, URL expiry, pseudonyms). It is front-loaded with the core purpose and then provides necessary edge-case behavior.
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 fields and semantics. It names the primary output values, explains truncation and time-limited URLs, and covers the pseudonymization edge case. For a tool with six parameters and complex operational behavior, this is highly complete.
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?
Input schema coverage is 100%, so the baseline is 3, but the description adds meaningful meaning beyond the schema: max_files triggers truncation, student_ids should be real Canvas IDs after pseudonym resolution, and the returned file_id is the way to request a fresh URL. This gives the agent guidance on how parameters interact with opaque behaviors.
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+scope statement: 'List every file attachment submitted by students across all assignments in a course.' It clarifies this returns a manifest of file entries (filename, file_id, content type, size), clearly distinguishing it from broader submission-listing tools like 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 description gives an explicit use case—bulk-archiving student work before a course expires or teacher account concludes—and points the user toward download_file for fresh URLs at download time. It doesn't explicitly contrast with list_files or list_submissions, but the clear scope and filters make the intended usage evident.
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 (readOnlyHint: true, openWorldHint: true) are supplemented by rich behavioral details: concluded courses are included by default, max_courses bounds scanning with most-recent-term-first ordering, truncated is set rather than silently dropping courses, and failed courses are skipped and listed in courses_failed. This goes far beyond the structured 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 dense, purposeful sentences. Each sentence delivers distinct value: scope and outcome, parameter options, and edge-case handling. No filler or repetition, and the main action 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 no output schema, the description adequately explains the return concept (every matching course with enrollment state and last activity) and covers important behaviors (truncation, failed courses, defaults). The tool's complexity is moderate, and the description leaves no major gaps for an agent to invoke it correctly.
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 coverage is 100% for the three parameters, and the description adds meaningful semantics beyond the schema: default values for include_concluded and max_courses, the ordering (most recent term first), truncation flag behavior, and per-course error reporting. This substantially enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Search') and resource ('the caller's teaching courses'), and includes scope (active and concluded) plus result details (enrollment state, last activity). This clearly distinguishes it from sibling tools like search_users or list_students, which operate on 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use this tool: to find a student by name/login/email across the caller's teaching courses, with defaults and flags (include_concluded, max_courses). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the 'explicit when/when-not/alternatives' level.
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?
Given destructiveHint=true, the description adds essential behavioral detail: partial failures are tolerated, one Canvas API call per assignment, V1 is create-only and already-existing overrides return 422 and appear in failed[], and not_found handling for nonexistent assignment IDs. The pseudonymization prerequisite (resolve_pseudonym first) is also disclosed. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense: each sentence covers a distinct concern (operation, failure tolerance, API call volume, create-only limitation, audit prerequisite, date format, return envelope, pseudonym note). It is front-loaded with the core purpose and then structured into operational details, though a bit verbose.
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 fully explains the return envelope (applied[], skipped[], failed[], not_found, summary) and the meaning of each array. It also covers failure semantics, prerequisites, pseudonymization, and performance implications. This is complete given the tool's complexity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds value by clarifying real-world semantics: 'Provide user_id as the real Canvas user ID', 'Dates must be ISO 8601 strings', and that omitting assignment_ids targets all assignments while nonexistent IDs go to not_found. This goes beyond the schema without fully re-explaining every field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fan a due-date / availability override for a specific student across all (or a filtered subset of) assignments in a course.' This clearly distinguishes it from siblings like set_student_quiz_accommodation (quiz-specific) and create_assignment_override (single assignment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to audit first ('Use list_assignment_overrides to audit first'), explains the create-only constraint with a concrete 422 failure mode, and provides a workflow for relative date shifts ('first call list_assignments with include=overrides to retrieve current dates, compute absolute timestamps, then call this tool'). This is strong usage guidance beyond simply naming alternatives.
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 explains that results silently stop at the limits, setting accurate expectations about behavior. This adds valuable context about potential truncation that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and to the point. It includes all necessary details without redundancy or fluff, making it easy for an agent to parse quickly.
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 fully covers the tool's purpose, limitations, and alternative for different needs. Given the simple nature of the tool (no parameters, no output schema), it is complete and self-contained.
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 no parameters, so the baseline is 4. The description does not add any parameter-related information since none exist, but it also does not mislead or omit anything necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (List), the resource (upcoming assignment events), and the scope (authenticated user). It distinguishes this tool from sibling tools like list_assignments or get_my_courses by targeting upcoming events specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (for upcoming assignments) and when not to (for longer ranges), providing a concrete alternative (list_calendar_events with type='assignment'). Also mentions the 1-week/20-event limits, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical non-obvious behavior beyond the readOnlyHint/openWorldHint annotations: the hard server-side caps (~1 week, 20 events), their non-adjustability, and silent truncation. This is highly valuable for an agent and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each purposeful: the first defines the action, the second provides crucial limitations and an alternative. No redundant wording, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description fully covers purpose, scope, limitations, and alternative behavior. It is complete enough for an agent to decide when to use it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty input schema is complete. The description clarifies the implicit 'current user' context, which is useful. Baseline for 0 parameters is 4, and no further parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the current user's upcoming calendar events and assignments.' This is a specific verb-resource pair and distinguishes from siblings like list_calendar_events by noting the cap and suggesting an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when not to use: 'For a longer or specific date range, use list_calendar_events with explicit start_date/end_date instead.' This explicitly names the alternative and the condition for choosing it.
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 (destructiveHint, openWorldHint), the description discloses critical behaviors: partial per-quiz failures are tolerated, fan-out is sequential, course-level errors propagate without an envelope, and the return envelope structure (scope, applied[], failed[], summary). This is rich, honest 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 dense but every sentence serves a purpose: purpose, mode distinction, quiz-type guidance, error handling, envelope details, pseudonym note. It is front-loaded with the primary action and uses no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema, destructive annotations), the description is comprehensive. It explains the return envelope despite no output schema, covers error handling for both modes, and addresses the pseudonymization context, leaving no critical gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds essential semantics absent from the schema: time_multiplier is a ratio (1.5 = 1.5x), not absolute minutes; assignment_ids behavior (omit for course-level, one call per assignment); and extra_attempts as 'additional attempts beyond default.' This adds clear value beyond property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Apply a time and/or attempts accommodation for a student across all New Quizzes in a course' and distinguishes between course-level and per-quiz modes. It also explicitly differentiates from the sibling tool set_student_quiz_accommodation for Classic Quizzes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: use this for New Quizzes, and 'For Classic Quizzes ... use set_student_quiz_accommodation instead.' It also explains the two usage modes (with/without assignment_ids) and the prerequisite to call resolve_pseudonym if CANVAS_PSEUDONYMIZE_STUDENTS is enabled.
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?
The description discloses the fan-out behavior ('one Canvas API call per quiz'), partial failure tolerance, and the exact structure of the returned envelope (applied/skipped/failed/not_found/summary). These go beyond the annotations, which only indicate destructive/open-world hints, providing essential operational 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?
Every sentence earns its place: purpose, exclusions, caveats, performance note, failure tolerance, return format, and pseudonym pointer. The description is front-loaded with the core action and progressively adds critical details without repetition.
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 complex fan-out tool with no output schema, the description fully specifies inputs, behavior, and return envelope, including edge cases (missing quizzes, skipped New Quizzes, partial failures). It covers the operational caveats (re-run after creating quizzes, pseudonym resolution) so an agent can invoke it safely.
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?
Although the schema already describes all six parameters (100% coverage), the description adds crucial semantics: the formula for extra_minutes from time_multiplier, the minimum 1-minute rule, the skip behavior for quizzes with no time limit, and the mutual exclusivity between time_multiplier and extra_time_minutes. It also explains the optional quiz_ids to limit scope.
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 ('Apply') and resource ('extra time and/or extra attempts to a specific student across all Classic Quizzes'), immediately distinguishing it from New Quizzes and sibling tools. It clearly states the scope (course or subset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool for New Quizzes ('use set_student_new_quiz_accommodation instead'), notes the run-timing caveat ('re-run after creating new quizzes'), and warns that due-date overrides are not handled. It also provides a pseudonymization prerequisite, giving clear when-to-use direction.
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-lms-mcp MCP server](https://glama.ai/mcp/servers/bruchris/canvas-lms-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bruchris/canvas-lms-mcp)

Score Badge

Copy to your README.md:

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

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