Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds real value beyond them by spelling out what the destructive path actually does (null removes the course's current grading standard) and what is returned (the updated course object).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action and followed by the ID source, the null semantics, and the return value. Each sentence carries information; only the return-value sentence is arguably redundant given the tool's obvious shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with no output schema, the description covers purpose, ID provenance, removal behavior, and return shape, with annotations carrying the destructiveness signal. A note on required permissions or the effect on existing assignment grades would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema's own grading_standard_id description already says 'or null to remove the current standard', so the description largely restates what the schema provides. It adds only the pointer to sibling tools as ID sources, which is the baseline-3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Apply an existing grading standard to a course') and immediately names the sibling tools that produce the ID it consumes (create_grading_standard, list_grading_standards). An agent can distinguish this from those siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tells the agent where to obtain grading_standard_id and explicitly covers the removal case (pass null). It gives clear positive context but does not state any when-not-to-use condition or permission prerequisite for the mutation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows this is a mutating, externally-visible write. The description adds the return value ('the new rubric association') but does not disclose what a destructive attach overwrites (e.g. an existing rubric association) or any permission requirement, leaving a meaningful behavioral gap against the annotation bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste: the primary action is front-loaded and the routing rationale plus return value follow. Nothing extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly states the return ('the new rubric association'), and it covers the sharing rationale for a 6-param mutation. It stops short of noting permissions or the destructive overwrite behavior implied by the annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already fully documented in the schema, including purpose, use_for_grading, and hide_score_total. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (attach), resource (existing course rubric), and target (assignment), and explicitly frames the distinction from create_rubric. An agent can immediately tell it apart from create_rubric and delete_rubric without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative (create_rubric) and the condition that selects this tool over it (sharing one rubric across many assignments instead of duplicating). It does not, however, state prerequisites such as required permissions or whether the rubric must already exist in the course beyond the word 'existing'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, yet the description adds substantial beyond-schema context: the exact severity taxonomy (error vs advisory), explicit limitations (no color-contrast checking, no list-misuse detection), the opt-in quizzes behavior, and required permissions. This is rich disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and long, but it is front-loaded with purpose and each clause earns its place by specifying checks, limitations, or permissions. Slight verbosity for a two-parameter tool keeps it below a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains that findings carry a WCAG success criterion and severity level, and it scopes exclusions and permissions. An agent has everything needed to invoke it correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 meaningfully that omitting `include` scans the default four sources and that `quizzes` must be passed explicitly for opt-in scanning, adding behavioral nuance beyond the raw schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (scan/audit) and resource (course content for WCAG 2.1 structural accessibility problems), and enumerates exactly what it detects. An agent can distinguish it from audit_course_links, check_course_setup, and Canvas's in-app Accessibility Checker without inspecting another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: requires instructor permissions, complements rather than replaces Canvas's in-app checker, and explains the quizzes opt-in. It does not explicitly route against sibling audit tools, but the usage conditions and exclusions are well stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, but the description adds real behavioral context beyond them: no outbound HTTP requests (structural checks only), the instructor-permission requirement, and the cost model (one extra Canvas API call per quiz). The 'no outbound HTTP requests' statement sits alongside openWorldHint=true, which is a nuance rather than a contradiction since the tool still calls the Canvas API.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what it scans and what it returns, then layers the quizzes nuance and the structural-check constraint. Every sentence carries information an agent needs; nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description sketches the return shape (cross-course references plus empty/malformed URLs), states the permission prerequisite, and clarifies scope limits. For a 2-parameter read-only audit tool, that is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and both parameters are fully documented in the schema itself, including the default four sources and the quizzes opt-in. The description restates the same semantics (defaults, opt-in quizzes, extra API cost) without adding format or syntax detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (scan a course's content for broken/outdated links and images), enumerates the scanned sources, and names the concrete failure class it detects (cross-course references after a course import). An agent can distinguish it from siblings like audit_course_accessibility, check_course_setup, or search_course_content without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when this applies: post-import stale-copy auditing and quizzes that break silently for students. The opt-in nature of `quizzes` is called out explicitly. It stops short of naming an alternative tool or stating when not to use this, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that: the return shape ("findings grouped by check with a plain-language detail per item") and an explicit permission requirement, both of which the annotations 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then scope boundaries, alternatives, and prerequisites in descending order of importance. No filler or repetition; every clause carries routing or behavioral information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes on the burden of describing the return shape and does so. Combined with permission requirements and the explicit exclusion of submission/performance analysis, an agent has everything needed to call this correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 goes further by spelling out in plain language what each check identifier actually detects (e.g. "published assignments still accepting submissions after their due date"), which lets the agent choose a `checks` subset without guessing at enum meanings. It does not, however, restate that omitting `checks` runs all five.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Run a factual course-readiness report") and then enumerates the concrete problem classes it detects, so the agent knows exactly what this tool produces. It explicitly distinguishes itself from list_students_needing_attention and get_missing_submissions, which is critical in a sibling set this large.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-not boundary ("config-health report only; it does not inspect student submissions or performance") and names the two alternative tools for that adjacent use case. It also states the prerequisite ("Requires instructor permissions in the course"), so the agent can route and gate correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=true, so the mutating/networked nature is covered. The description adds nothing beyond that: it does not say who the comment is attributed to, whether it notifies the student, whether it can be edited or removed afterward, or what permissions are required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the operation front-loaded and zero filler. It is efficient, though the terseness borders on under-specification rather than true concision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a four-required-parameter mutation with no output schema and no annotation coverage of permissions or side effects. The description leaves the key ambiguity unresolved: whether user_id identifies the commenter or the submission's author, and what happens on success or failure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (course_id, assignment_id, user_id, comment) are already documented in the schema. The description adds no syntax, format, or semantic detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Add') and resource ('text comment to a submission'), which is unambiguous about the operation. It does not, however, differentiate itself from any sibling or clarify how it relates to nearby tools like list_submission_comments_needing_attention or grade_submission.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer from the name alone that this is the tool for leaving feedback on a student submission.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint: true, and the description aligns by noting creation action, though it doesn't detail irreversible effects or permission requirements. It clarifies that new_appointments define time slots and mentions the default draft behavior implicitly through the publish parameter. The description adds value by specifying the structure of new_appointments, which is not fully in the schema, but it doesn't disclose any potential side effects or prerequisites beyond what's in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, two sentences, and front-loads the core purpose and required attributes. It efficiently communicates the essential usage without redundant detail, earning a high score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with no output schema, the description covers the essentials: required fields, the salient new_appointments format, and hints at the draft/publish behavior via the publish parameter. However, it doesn't mention return behavior or error cases, and doesn't detail all optional parameters, but given the schema's richness, it is reasonably complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters like context_codes and title are already well-documented. The description reinforces the required parameters and provides an example of context_code format ('course_123') and new_appointments structure, which adds a bit more clarity. However, it doesn't explain optional parameters like participant_type or max_appointments_per_participant beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new appointment group in Canvas Scheduler)Skip, with specific details about required parameters (context_code and title) and new_appointments as [start_at, end_at] pairs. It distinguishes from siblings like list_appointment_groups and update_appointment_group by focusing on creation, but doesn't explicitly name a sibling or contrast with other creation tools like create_calendar_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives some usage context (e.g., provide at least one context_code and a title) but does not explicitly state when to use this tool versus alternatives like create_calendar_event or list_appointment_groups. It implies it's for setting up sign-up slots in Canvas Scheduler, but no direct comparison or exclusion of alternatives is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether the assignment is created published or unpublished by default, what happens to date inconsistencies (unlock_at/lock_at), what permissions are required, or what the call returns. For a 12-parameter write operation, that is a meaningful omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is front-loaded and contains no filler, which is good structure. Against a 12-parameter tool with grading and date semantics, however, it is under-specified rather than truly concise, leaving the definition thin.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only destructive/openWorld annotations, the description would need to carry defaults, side effects, and required-privilege context. It supplies none of these, so an agent knows what the call does but not how to call it safely or what state it leaves behind.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the 12 parameters is documented in the schema itself, including the ISO 8601 date constraints and cross-field ordering rules. The description adds no additional meaning beyond the schema, which is the baseline expectation at full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new assignment in a course'), so an agent knows exactly what operation is performed. It does not, however, differentiate itself from close siblings like update_assignment, create_assignment_override, or set_student_assignment_dates, which a caller must distinguish on their own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no stated prerequisites (e.g., that course_id must reference an existing course the caller can write to), and no mention of alternatives such as update_assignment for modifying an existing assignment. The agent is left to infer all routing decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations supply destructiveHint=true and openWorldHint=true, and the description adds real behavioral context beyond them: a 422 error when a student-set override already exists, the partial-update semantics ('omit a date field to leave the corresponding date unchanged'), and the pseudonymization prerequisite. It stops short of warning that an existing override for the same target may be replaced or how to undo.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then constraints, then sequencing, then format — a logical order with little waste. It is fairly dense with rules, but each sentence carries distinct, non-redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation with no output schema and only two annotations, the description covers the key constraints, error behavior, and prerequisites an agent needs to invoke it correctly. It omits permission requirements and expected response shape, which would round it out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the per-parameter descriptions already carry most semantics. The description still reinforces value by surfacing the tool-level 'exactly one target' and 'at least one date' rules plus the ISO 8601 example format in a single place, though it does not add new per-parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Create a due-date / availability override for a specific assignment' — and immediately enumerates the three override target types. This clearly distinguishes it from sibling tools 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit preconditions: exactly one of student_ids/course_section_id/group_id, at least one date field, ISO 8601 formatting, auditing via list_assignment_overrides to avoid a 422, and calling resolve_pseudonym first when pseudonymization is on. This is a near-complete decision and sequencing guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description provides no behavioral details beyond the action itself. The annotation destructiveHint: true suggests the operation may have destructive side effects, but the description doesn't clarify what those are (e.g., overriding existing events, requiring specific permissions). It doesn't mention that it creates a permanent record or any side effects like notifications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff. It's appropriately concise for a simple create operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create operation, the description is minimal. It doesn't specify what the response will be (e.g., the created event object), which is important for the agent to process the result. Since there's no output schema, the description should at least mention the return type. It also doesn't mention any validation or error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 no extra meaning beyond the schema, such as explaining the relationship between start_at and end_at or the format of context_code. It doesn't compensate for any ambiguity in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Create') and resource ('new calendar event') and explicitly scopes to Canvas. It distinguishes from sibling tools like list_calendar_events and update_calendar_event by the verb 'create'. However, it doesn't specify whether this creates events in course, user, or group calendars, which could be ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this vs alternatives. It doesn't mention that update_calendar_event exists for modifications or list_calendar_events for querying. No context on prerequisites like permissions or whether the context_code must exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare openWorldHint/destructiveHint; the description adds real value beyond them by disclosing the async contract, the immediate return with an export ID and workflow_state 'created', and that the download link is time-limited. It never reconciles why destructiveHint is set, which for a pure export is an unexplained flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: purpose first, async contract second, next-step routing third. Every sentence carries information and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly carries the return-value burden — export ID, initial workflow_state, and the downstream source of the download link. Parameters are fully covered by the schema, so nothing an agent needs to invoke the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the enum values are fully documented in the schema, so the description's format list adds nothing new. Baseline 3 for a fully-covered 2-parameter schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb ('Start a Canvas course content export') plus the resource and supported formats (Common Cartridge / QTI / zip). An agent can distinguish it from the read-side siblings get_content_export and list_content_exports without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent onward, naming get_content_export as the polling tool and stating the condition (once the export finishes, to get the time-limited link). It lacks any 'when-not' guidance — notably no disambiguation from the sibling create_content_migration, which is the natural confusion case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true and openWorldHint=true, and the description usefully adds that the call is asynchronous, returns immediately, and yields a migration ID plus progress_url. It stops short of warning that a migration can overwrite/replace existing course content (the destructiveHint implication) or noting any permission prerequisites, which would be the higher-value additions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler: the first names the operation and its variants, the second covers the async contract and the polling path. Front-loaded with the action, and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by describing the immediate return (migration ID, progress_url) and the polling workflow. It lacks any note on permissions or irreversible content replacement, so a complex, destructive, nested-object tool is not fully covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 restates the migration types already enumerated in the migration_type enum and does not add syntax or format detail for settings, selective_import, or date_shift_options beyond what the schema documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Start a content migration') and enumerates the five concrete migration types (course copy, Common Cartridge, zip, QTI, Moodle), which maps directly to the migration_type enum. An agent can distinguish this from siblings like create_content_export or list_content_migration_types without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tells the agent what to do after invocation — poll get_content_migration or progress_url — which is explicit follow-up guidance. However, it never contrasts this tool with adjacent siblings such as create_content_export (export vs. import) or list_content_migration_types (to discover valid types), leaving that selection to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=true, so the safety profile is partly covered. The description adds only 'Returns the created course object' and says nothing about permission requirements, idempotency on duplicate names, or the effect of omitting start_at/end_at — thin context for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, action front-loaded, with zero filler. Nothing in the text is redundant or misplaced.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description only notes that a course object is returned without any indication of its shape. For a 5-parameter write tool that creates a persistent resource, the absence of permission and side-effect context leaves meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (name, account_id, course_code, start_at, end_at) are already documented with formats and examples. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new course') scoped to a Canvas account, which cleanly separates it from get_course, update_course, and list_courses in the sibling set. It does not explicitly name a sibling it is not, so it falls 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus update_course or other creation tools, and no prerequisites such as the account-admin permission a Canvas course creation typically requires. The agent gets no context beyond the bare action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=true, so the agent has the safety profile. The description adds nothing behavioral beyond that — it does not mention permissions, that is_announcement can be silently downgraded (a critical gotcha that appears only in the schema), or any post-creation 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, which is efficient. It is arguably under-specified rather than over-long, but the structural discipline is sound.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with no output schema and 8 parameters, and the description covers none of the operational concerns — no permission requirements, no scheduling semantics for delayed_post_at, no announcement-downgrade caveat. For a create tool with this much surface area, the description is too thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 8 parameters are documented in the schema itself, establishing a baseline of 3. The description contributes no additional parameter 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Create a new discussion topic'), and 'in a course' clarifies the scope. However, it makes no attempt to distinguish itself from close siblings like post_discussion_entry, create_page, or list_discussions, so the agent gets no differentiation help.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent cannot tell from this text whether to use this tool versus create_page or post_discussion_entry.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare openWorldHint and destructiveHint; the description adds the admin prerequisite, the pre-send descending sort, the Canvas singular/plural key mismatch, and the returned id's downstream use. These are meaningful behavioral details beyond the structured annotation fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then parameter constraints, then return and id usage; every sentence is information-bearing. It is slightly long due to Canvas POST/body key internals, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the return-value burden and does so by stating the created object includes its id and how to use it. It covers creation context, naming, admin requirements, and activation path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter. The description reinforces the 0–1 lower-bound value semantics with an example and adds the non-obvious pre-send sort order, though some of this repeats the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Create') and resource ('grading standard'), plus its scope (course or account). It also distinguishes itself from nearby tools by naming apply_grading_standard_to_course as the activation step for the returned id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly explains that either course_id or account_id is required, that account context requires admin, and how to activate the result with apply_grading_standard_to_course. It lacks explicit when-not-to-use guidance or a direct comparison against list_grading_standards.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare openWorldHint=true and destructiveHint=true, so the agent knows this is a write operation with potential side effects. The description adds nothing beyond the purpose: it does not explain what gets created, what the destructive hint implies, whether modules can be deleted later, or any auth/rate-limit constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is front-loaded and has no wasted words. It is appropriately concise, though it is arguably too sparse for a mutation tool with five parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation tool with five parameters and no output schema, the description is incomplete. It omits usage context, behavioral implications of the destructive hint, and any practical guidance beyond the basic purpose already implied by the name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 five parameters (course_id, name, position, unlock_at, prerequisite_module_ids). The description adds no parameter meaning 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new module in a course') so an agent can tell it creates a module rather than a module item. However, it does not distinguish itself from siblings like create_module_item or update_module, which also create or modify module-related entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, required context (e.g., course_id must exist), or when to prefer update_module or create_module_item instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=true, so the mutation profile is covered. The description adds essentially nothing beyond that: no side effects, no effect on module ordering/positions, no note that unpublishing or permissions may be required. No contradiction, but minimal added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It is efficient, though the parenthetical type list duplicates the schema enum and could have carried conditional-parameter guidance instead.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and full parameter documentation, the description is minimally adequate. It omits the conditional required-field logic per item type (which types need page_url vs content_id vs external_url), leaving the agent to reconstruct that from schema prose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including the conditional ones (page_url for Page, content_id for File/Discussion/Assignment/Quiz, external_url for external items). The description merely restates the type enum, adding no meaning beyond the schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Add') and resource ('item ... to a module'), and enumerates the accepted item types. It is distinguishable from siblings like create_module and update_module_item, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus update_module_item or create_module, nor any prerequisite (e.g. that the target module must already exist). The agent must infer usage entirely from the name and siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=true, so the agent knows this is a mutating, external-facing operation. The description adds the LTI/New Quizzes engine context but says nothing about side effects beyond the safety profile — e.g., whether the quiz is created unpublished, whether it starts empty and requires items, or what identifier is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the core action stated first and the disambiguation second. Nothing is repeated from the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 full schema coverage and annotations covering the safety profile, the description supplies adequate context: what it creates and which engine. It is slightly thin on lifecycle behavior (empty quiz needing create_new_quiz_item, publish state, return value), but no output schema exists so return details are not strictly required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 8 parameters (title, due_at, lock_at, unlock_at, published, instructions, points_possible, course_id) are already documented in the schema. The description adds no parameter-specific meaning, which is the expected baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Create') plus the exact resource and engine variant ('a New Quiz (LTI) in a Canvas course'). The second sentence tells the agent precisely which quiz engine this tool targets, so it is not confusable with Classic quiz operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative route for Classic quizzes ('for Classic quizzes use create_quiz'), giving the agent a clear routing rule. However, that named alternative does not appear in the sibling tool list, and no other usage conditions (permissions, prerequisites, publish behavior) are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag this as a mutating, open-world operation (destructiveHint=true, openWorldHint=true). The description adds genuinely new behavioral context beyond that: Canvas rate-limits rapid sequential creates, calls must be serial, and large batches need chunking with pauses. It does not state what a create destroys or what permissions are needed, keeping it below the top band.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with purpose and supported types before the concurrency/batching constraints. Every sentence carries distinct, actionable information with no padding or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers purpose, supported item types, and the rate-limit/batching behavior that an agent must respect to succeed. It leaves out the return shape and whether providing position overwrites an existing item, but the safety profile is carried by the annotations, so the remaining gaps are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 80% schema coverage the baseline is 3, and the description earns an extra point by spelling out the five interaction_type_slug variants (choice/MCQ, true-false, essay, matching, numeric), which maps each item shape to its schema branch. It does not add per-field detail beyond what the schema already documents for course_id, assignment_id, points_possible, and position.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create an item (question) in a New Quiz (LTI)') and adds the '(question)' gloss plus the LTI scope, which cleanly separates it from create_new_quiz and the legacy quiz-question tools. It also enumerates the five supported interaction types, so an agent knows the shape of work it can do without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete operational guidance: call serially, not in parallel, and chunk with pauses above 50 items. That is strong 'how to use' context, but it does not name an alternative tool or state when this tool is the wrong choice versus update_new_quiz_item or delete_new_quiz_item, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=true, which is a notable (and counterintuitive) signal for a create operation, yet the description adds no behavioral context at all — no mention of default published state, editing permissions, side effects, or what happens to an existing page with the same title. It neither explains nor reconciles the destructiveHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, front-loaded sentence with zero waste, but it is under-specified rather than genuinely concise — the brevity comes at the cost of any useful detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the input schema is fully documented, so the mechanical calling information is present. However, for a creation tool flagged destructiveHint, the description omits default publishing behavior and duplicate-title handling, leaving an agent without enough context to call it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all five parameters individually documented (body, title, course_id, published, editing_roles). The description adds nothing beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Create') and resource ('a new wiki page') plus scope ('in a course'), so an agent knows exactly what it does. It stops short of differentiating itself from siblings such as update_page or create_module, but the resource noun is unambiguous enough that confusion is unlikely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives (update_page, create_module, create_discussion), no stated prerequisites or permissions, and no exclusions. Usage is only inferable from the verb itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true and openWorldHint=true, yet the description offers no behavioral context: what a prior assignment is replaced by, whether duplicate assignments stack or overwrite, or any permission requirements. Since the destructive hint is exactly the kind of behavior the description should elaborate on, its silence here is a real gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with no waste, correctly front-loaded. However, it is terse to the point of under-specification rather than being admirably compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with no output schema, the description leaves out assignment semantics, permissions, and side effects. It is calling-instruction-sufficient only at the bare minimum level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four IDs are already documented in the schema with their Canvas semantics. The description adds no additional meaning about 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Assign a user to peer-review a submission'), which is enough to distinguish it from the read-oriented siblings list_peer_reviews and get_submission_peer_reviews. It does not explicitly name those siblings, but the action/query split is evident from the name and phrasing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the alternatives, no prerequisites (e.g. that the course must have peer reviews enabled or that the submission must exist), and no note on whether assigning an already-assigned reviewer is allowed. The agent must infer all of this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (destructiveHint=true, openWorldHint=true, consistent with a create). The description adds real behavioral value beyond that: it documents the return shape ({ rubric, rubric_association? }) and explains that rubric_association.id is the association_id consumed by submit_rubric_assessment, enabling correct chaining. It omits permission/auth requirements, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight, front-loaded sentences with zero filler: the action, the optional linking behavior, then the return contract. Every clause earns its place by either describing behavior or enabling downstream chaining.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given nested criteria/ratings objects, four parameters, and no output schema, the description does the necessary work by describing the return payload and the association linkage. It stops short of documenting authorization or course-state prerequisites, leaving a small gap for a mutating, open-world tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 and the schema already documents title, criteria, ratings, and association fields. The description adds meaning above the schema by tying the nested association output back to submit_rubric_assessment's association_id, a workflow-level semantic not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Create a new rubric in a course") with the composed entity (criteria and rating levels), which separates it from the read/delete rubric siblings. It does not explicitly distinguish itself from attach_rubric, the closest overlapping sibling, so it falls just 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes the association can be linked "immediately" and otherwise is optional, which implies usage context. However, it never states when to use this versus attach_rubric or whether a course must already exist, leaving the agent to infer alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral value beyond them by disclosing the side effect on existing reservations and that cancel_reason drives participant notifications. It does not state irreversibility or permission requirements, keeping it below 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the destructive action stated first and the optional notification parameter second. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter destructive tool with no output schema, the description covers the action, its cascade effect on reservations, and the optional notification parameter. It leaves out only secondary details such as reversibility and required permissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces that cancel_reason produces cancellation notifications, which slightly enriches the schema's 'Message to include in cancellation notifications', but adds no format or constraint detail. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete an appointment group'), which is unambiguous against siblings like create_appointment_group, update_appointment_group, get_appointment_group, and list_appointment_groups. It stops short of explicitly naming those siblings, so it is clear but not differentiated by explicit contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (destructive removal of an existing group) and hints at the cancel_reason workflow, but never states when to use this versus update_appointment_group or what prerequisites (ownership, permissions) apply. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely covered. The description adds 'This action is permanent,' which reinforces irreversibility beyond the base destructive flag. It says nothing about side effects on submissions, grades, or whether the assignment must be unpublished first.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, front-loading the action and following with the one caveat that matters. Nothing extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter delete whose safety hints are already in annotations and whose inputs are fully documented in the schema, the description is nearly complete. The only minor gap is the absence of any note on cascading effects (e.g., associated submissions) that would matter for a destructive operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so course_id and assignment_id are already documented in the schema. The description adds no syntax, format, or scoping detail beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Delete an assignment from a course'), which is enough to distinguish it from sibling delete_* tools that target different resources. It does not, however, explicitly differentiate itself from adjacent assignment tools like update_assignment beyond the verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool, no prerequisites, and no mention of related alternatives. The only additional context is a warning that the action is permanent, which is caution rather than usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare destructiveHint=true and openWorldHint=true. The description adds that the action is 'permanent,' which reinforces irreversibility, but it does not cover permissions, side effects on discussion entries, or any rate limits. With annotations covering the safety profile, this is a modest addition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste. The core action is front-loaded and the permanence warning follows immediately, making it efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter destructive tool with full schema coverage and annotations declaring destructiveness, the description provides the essential action and permanence warning. It is nearly complete, though it could mention effects on associated discussion entries or required permissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are fully documented in the schema. The description adds no parameter-level detail (e.g., ID format or constraints), which is consistent with the baseline 3 when schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Delete') and resource ('discussion topic') with scope ('from a course'), clearly distinguishing it from siblings like update_discussion and list_discussions. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance or alternatives are mentioned. The description only restates the action; it does not say when to choose this over update_discussion or how to confirm intent before a permanent deletion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. 'This action is permanent' reinforces irreversibility but largely restates the destructive hint and adds nothing about recovery, cascading effects, or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two terse sentences with the action front-loaded and the irreversibility warning second; nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive tool with full schema coverage and no output schema, the description plus annotations are nearly sufficient. Only minor behavioral detail (e.g., behavior when the file is missing or already deleted) is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single well-documented file_id parameter (integer or numeric string, positive). The phrase 'by ID' matches the schema without adding format or constraint detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Delete a file') plus the required key ('by ID'), so the action is unambiguous. However, it never distinguishes itself from siblings like get_file, download_file, or list_files; an agent must infer the boundary from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus alternatives, nor any prerequisites (ownership/permissions) or warnings about when not to call it. The only steer is the implication of the word 'Delete'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint and idempotentHint, but the description adds crucial behavior beyond them: for ExternalUrl, ExternalTool and SubHeader items the content itself is deleted, while for Assignment, Page, Quiz, File and Discussion items only the link is removed and the underlying content survives. This is exactly the kind of consequence disclosure an agent needs before calling a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences plus a one-clause recovery hint. The core action is front-loaded, the critical distinction follows immediately, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive module-item deletion with no output schema and full schema coverage, the description supplies the missing behavioral nuance: which item types lose content versus only a link, and how to recover via create_module_item. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so course_id, module_id and item_id are already documented in the schema. The description adds item-type behavior but no additional syntax, format, or constraint details for the parameters themselves, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Remove') and resource ('an item from a module'), and distinguishes the tool from siblings like create_module_item by naming the re-add alternative. The type-dependent outcome further sharpens what 'remove' means here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use it and what happens by item type, and names create_module_item for re-adding. It does not explicitly state when not to use it (e.g., prefer update_module_item to modify rather than remove), so it falls short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is known. The description's 'This action is permanent' reinforces destructiveness but is largely redundant, and it never mentions the idempotent behavior or what else (items, submissions) is removed with the quiz.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and resource, then the permanence warning, then the parameter caveat. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, the description covers what is deleted, that it is permanent, and which ID to supply. It could still note required permissions or side effects (e.g. associated items/submissions), but nothing essential for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, but the description adds genuine disambiguation by warning to pass assignment_id rather than quiz_id — a real trap given the sibling quiz tools. It does not clarify the course_id vs assignment_id relationship beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and a precise resource (New Quiz (LTI) in a Canvas course), and the '(LTI)' qualifier plus the assignment_id note clearly separate it from the classic-quiz sibling delete_quiz and from delete_new_quiz_item. An agent can identify the tool without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by naming the resource type, and the 'Use assignment_id (not quiz_id)' note helps route between similar deletion tools. However, it never explicitly says when to choose this over delete_quiz or delete_new_quiz_item, nor what prerequisites (role/permission) apply.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the destructive nature is known. 'This action is permanent' adds the irreversibility angle beyond the annotations, which is useful, but nothing is said about cascade effects (student scores, submissions, quiz totals) or permission requirements. A modest addition over what structured fields already carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the target of deletion and the permanence warning front-loaded; nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-required-param delete with full schema coverage, no output schema, and annotations covering the safety profile, the essentials (what is removed, that it cannot be undone) are present. It would be stronger with a note on impact to student data or quiz structure, but nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents item_id (including the string-not-numeric caveat), course_id, and assignment_id. The description adds no parameter-level meaning, so the baseline 3 applies when the schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete an item (question) from a New Quiz') and the '(LTI)' qualifier plus 'New Quiz' disambiguates it from the classic-quiz siblings like delete_quiz_question and delete_quiz. It stops short of naming that alternative directly, so an agent must infer the split from the New Quiz framing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance. The sibling set contains delete_quiz_question (classic quizzes) and delete_new_quiz, and the description never says which to pick or what prerequisites exist. The New Quiz naming implies the scope but leaves the routing entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows this is a destructive operation. The description adds the specific behavioral detail that the action is permanent, but does not mention cascade effects, permission requirements, or whether special pages (e.g., front page) are protected. Moderate added value 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and followed by the permanence warning. Every word earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and annotations cover the safety profile. For a two-parameter delete tool the description is nearly complete, though it could note whether deletion is reversible/undoable or subject to restrictions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both course_id and page_url are fully documented in the schema itself. The description adds no parameter-level detail beyond what the schema provides, making the baseline of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('delete'), resource ('wiki page'), and scope ('from a course'), which cleanly distinguishes it from adjacent siblings like get_page, update_page, and create_page. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the clear delete-a-page purpose, but the description offers no explicit when-to-use guidance, prerequisites, or conditions under which deletion might be disallowed. No alternative tool is needed for this operation, so the omission is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the destructive nature is known. The description adds real value by asserting the effect is permanent/irreversible, which annotations do not state. It says nothing about required permissions, who is affected, or whether the reviewer is notified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The action and its target are front-loaded, and the permanence warning earns its place as the second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple destructive operation with no output schema and fully documented parameters, but for a permanent deletion it omits what state is destroyed (peer review record vs. review data), permission requirements, and side effects such as notifications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four required IDs (course, assignment, submission, user) are already documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: "Remove a peer review assignment from a submission." An agent can distinguish this from create_peer_review, list_peer_reviews, and get_submission_peer_reviews, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no named alternatives. The only steer is the warning that the action is permanent, which is a caution rather than usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description still adds real value by disclosing the blast radius — child questions and all student submissions are removed, not just the quiz shell. It stops short of stating auth/permission requirements, so it is a strong 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero filler. The destructive scope is front-loaded, and the classic-vs-new-quiz routing is saved for the second sentence where it belongs as a disambiguation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter delete tool with annotations covering the danger profile and no output schema to explain, the description covers everything an agent needs to call it correctly: what it deletes, how much it deletes, and which sibling to use instead. Only permission/authorization prerequisites are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both required parameters (course_id, quiz_id) are documented in the schema itself, so the baseline is 3. The description reinforces that quiz_id means a Classic quiz and that course_id scopes the deletion, but adds no format or constraint detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('permanently delete a Classic quiz from a course') and immediately bounds the scope by enumerating what is destroyed — questions and every student submission. It explicitly distinguishes itself from the sibling delete_new_quiz, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit selection condition — 'Classic Quizzes only' — and names the alternative tool for the New Quiz (LTI) case. This is exactly the when-this/when-other guidance the dimension asks for, with nothing left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds the irreversibility qualifier 'permanently' and the Classic-quiz-only restriction, which sharpens the blast radius. It does not, however, add anything about side effects on existing submissions or whether the deletion is recoverable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the destructive action front-loaded and the disambiguation clause placed immediately after. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema needed for a delete and all three required params documented, the definition is nearly complete; annotations carry the safety profile. The only missing nuance is the downstream effect of removing a question from an already-administered quiz.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so course_id, quiz_id and question_id are already documented in the schema. The description adds no format, ordering, or referential detail (e.g. that question_id must belong to quiz_id) beyond what the structured fields provide. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Permanently delete'), the exact resource ('a single question'), and the scope ('from a Classic quiz'). It also names the sibling it must not be confused with, delete_new_quiz_item, so the agent can distinguish it without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the applicability constraint ('Classic Quizzes only') and the routing alternative ('use delete_new_quiz_item for a New Quiz item'). Both the when and the when-not are given, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description still adds real value by disclosing what the deletion actually destroys ('removing it from every assignment it is attached to'), the permanence, and that the deleted object is returned — none of which the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the permanence and cascade consequence front-loaded before the return-value note. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by stating the return value. Combined with full schema coverage and destructive/idempotent annotations, an agent has enough to call it correctly; only permission requirements and failure behavior on ambiguous rubric IDs are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both course_id and rubric_id are documented in the schema with type/allowed-value constraints. The description adds only indirect semantics ('from a course' gestures at course_id) and no format or validation detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource+scope: permanently delete a rubric from a course. The resource ('rubric') cleanly separates it from the many other delete_* siblings (delete_assignment, delete_discussion, delete_quiz), and the cascade clause adds scope detail beyond the bare name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the destructive verb and the stated cascade effect, which tells the agent this is a high-consequence action when a rubric is shared across assignments. However, no explicit when-to-use/when-not guidance, no mention of alternatives (e.g. attach_rubric or a detach/remove option), and no stated prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 valuable behavioral details beyond annotations: text files return readable text, binary files return base64, and files larger than 10 MB are refused. This meaningfully informs the agent about return behavior and limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences with zero waste. The most important information (what it downloads) is front-loaded, followed by return formats and the size limit, all earning their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return values and does so by distinguishing text versus base64 binary returns. It also states a hard 10 MB limit. It does not mention error conditions or the optional course_id scoping, but these are minor gaps for a read-only download tool with fully documented parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 file_id and course_id fully. The description adds no parameter-level detail (e.g., course_id scoping), so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Download) and resource (Canvas file content by ID), making it clear what the tool does. It does not explicitly differentiate from sibling tools like get_file or list_files, so it falls 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives such as get_file (metadata) or list_files (listing), nor does it state prerequisites or exclusions. It only describes output behavior, not usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true and openWorldHint=true, but the description adds nothing beyond them: it does not say whether enrolling an already-enrolled user errors or duplicates, whether the call is idempotent, what permissions are required, or that it is a write that changes course membership. For a mutation with no output schema, this is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler and no redundancy. It is efficient, though the brevity contributes to the missing behavioral and usage context rather than being purely a virtue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four parameters, two enums, no output schema, and only destructive/openWorld annotations, the description should carry more: effect of the enrollment_state default, duplicate-enrollment behavior, and required permissions are all absent. It is not sufficient on its own for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 course_id, user_id, type, and enrollment_state in detail. 'With a specified role' loosely gestures at the type enum but adds no meaning beyond the schema's enum list and default note, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Enroll a user in a course') and signals that a role must be supplied, so an agent can identify the operation. It does not, however, distinguish this from the nearby sibling 'remove_enrollment' or note how it relates to 'list_enrollments'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites (permissions, course context), and no reference to alternative or complementary tools such as remove_enrollment for reversing the action. The agent must infer all of this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/non-destructive annotations, it discloses substantial behavior: V1 processes one student per call, curves and fudge points cannot be reflected and a caveat is emitted above a 0.5 pp discrepancy, grading-period courses reconcile against the cross-period grade, and pseudonymized student IDs require a prior resolve_pseudonym call. This is unusually rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The output contents are front-loaded in the first sentence, followed by a use-case sentence and a scannable Limitations list. It is dense and a little long, but nearly every clause carries actionable information, so waste is minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 enumerating exactly what is returned (weights, drop rules, per-group breakdowns, letter grade, reconciliation), plus scope, limits, and prerequisites. An agent has everything needed to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 cross-reference value the schema lacks: the pseudonymization prerequisite for student_id and the note that omitting it computes for the authenticated user. It largely restates assignment_group_id narrowing already covered by the schema, keeping it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Recomputes and explains the weighted course grade for a student') and enumerates the exact outputs (group weights, drop rules, per-group breakdowns, letter grade mapping, Canvas reconciliation). An agent can distinguish this from get_my_grades, project_grade, and explain_grading_policy without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit use case: 'Use this when you need to verify that Canvas's displayed grade matches the rules, or to explain... how their grade was calculated.' The Limitations block supplies clear when-not conditions (one student per call, curves/fudge points unavailable, pseudonymization prerequisite). It stops short of naming a specific sibling alternative for those excluded cases, so it is strong but not fully routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint, but the description adds substantial context beyond them: the late/missing section requires instructor or admin permissions, students receive only two sections plus a caveat, and a shareable plain-language summary is produced. These auth and data-visibility behaviors are not derivable from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then a bulleted breakdown of returned sections that each earn their place by clarifying scope. Slightly long, but the structure is scannable and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 return-value burden and does so thoroughly by listing all returned sections plus the summary paragraph. Permission caveats and the sibling routing close the remaining gaps an agent would need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (course_id) with 100% schema description coverage, so the schema already documents it fully. The description adds no format or type detail beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (explains) and resource (grading automation rules) and enumerates the exact facets returned (missing-submission, late-submission, weighting, scheme). It distinguishes itself from the sibling explain_grade by naming it as the compute-oriented alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use explain_grade to compute an actual weighted grade for a specific student, implying this tool is for understanding policy instead. It also states the permission-conditioned access model (instructor/admin vs student), giving clear context for when the tool will return partial data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint. The description adds real behavioral context: it explains the matching algorithm (display name + size), discloses why (no content hash in Canvas file listings), and explicitly states the edge case that same-name files of different sizes are not duplicates. This is meaningful disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then the motivation, then the matching-logic caveat. No redundant restatement of the name and every sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only detection tool with no output schema, the description conveys what it finds and how grouping works. It does not describe the return shape (e.g., whether duplicates are grouped or listed per file), but the conceptual output is clear enough to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both course_id and folder_id are fully documented in the schema. The description implies course scoping ('a course's Files area') but adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Find duplicate files in a course's Files area') and defines what counts as a duplicate (same name and size). It clearly separates itself from siblings like list_files and get_file by being an audit/detection tool, and even names delete_file as the follow-up action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when this matters ('typically left behind by repeated course copies') and routes the agent to the cleanup tool (delete_file). It lacks an explicit when-not or a contrast with list_files, but the intended usage scenario is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already mark this as read-only, but the description adds valuable behavioral detail beyond that: truncation behavior with `truncated: true`, course-scan ordering by most recent term, and per-course error handling via `courses_failed`. This is strong transparency, especially given the partial-failure semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, with the core purpose front-loaded and every sentence contributing operational details. There is no filler, repetition of the name, or redundant restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description explains what the caller can expect: matching courses, enrollment state, last activity, `truncated`, and `courses_failed`. Combined with the parameters and annotations, an agent has everything needed to invoke and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all three parameters, so the baseline is 3. The description adds meaning beyond the schema by explaining defaults (`include_concluded` defaults to true), the effect of `max_courses`, and how `truncated` is set when the cap is exceeded. This enriches parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search'), a specific resource ('the caller's teaching courses'), and a clear object ('a student by name, login, or email'). It also specifies what is reported, which distinguishes it from nearby search/list tools like search_users or list_course_users.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when this tool is appropriate: searching across the caller's own teaching courses, including concluded ones by default. It does not explicitly name alternatives or exclusions, but the scope and behavior are precise enough for an agent to select it correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 nothing beyond the annotations — no note on permissions, visibility scope, or what an account lookup returns — so it earns little credit for behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the resource and lookup key come first and nothing needs to be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with full schema coverage and annotations carrying the safety profile, the description is essentially complete. Only a brief note on when to prefer it over list_accounts is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is only one parameter, so the schema fully documents account_id including its integer-or-string pattern. The description's 'by ID' adds no format or constraint detail beyond that, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('Canvas account') and the lookup key ('by ID'), which distinguishes it from the sibling list_accounts. It stops short of naming siblings explicitly, so a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_accounts or list_sub_accounts. The agent must infer that this is the single-account lookup versus a listing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 profile is covered. The description adds the useful nuance that it returns report *types* (a catalog) rather than report data, but omits pagination, auth scope, or any other behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with the resource and scope front-loaded and no filler. It could be slightly sharper about the types-vs-data distinction, but there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 one fully documented parameter, no output schema, and annotations covering the safety profile, the description is largely sufficient. The main gap is the absence of any usage context relative to sibling account tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single account_id parameter fully documented in the schema. The description's phrase 'for a Canvas account' implies the parameter but adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (List), resource (report types), and scope (a Canvas account), which clearly separates it from report-retrieval tools. However, it does not explicitly differentiate itself from the many other account-level siblings such as get_account, list_account_courses, or list_account_users.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of what to do with the returned report types. The agent must infer usage entirely from the name and one-line description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety profile is covered. The description adds that time slots and participant counts are included in the response, which is useful behavioral context about return scope, though it doesn't cover pagination, permissions, or error behavior.