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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns (it is a diagnostic check). The description adds context about the credential's storage and validity, but doesn't mention output format or any potential side effects (e.g., network calls). Still, with strong annotations, this is adequate. No contradiction.

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

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

Two sentences, front-loaded with the core function ('Diagnose the Canvas connection') and followed by clear usage instructions. Zero waste, every word adds value.

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 and no parameters, the description sufficiently covers what the tool does and when to use it. It doesn't describe the return format (e.g., JSON), but for a diagnostic tool, the guidance on usage is more critical. With strong annotations, this is complete enough.

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?

There are no parameters, so schema coverage is 100%. The description adds value by explaining what the tool examines (credential, storage, validity) without needing to explain parameters. Baseline for 0 params is 4, and the description enriches understanding of what 'status' means.

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's purpose: 'Diagnose the Canvas connection' and specifies exactly what it checks (which credential, where stored, whether it works). It distinguishes itself from sibling tools by focusing on connection/auth status, which no other sibling suggests.

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 instructs when to use: 'Run this first when something fails, or before a scheduled job, to distinguish an expired session from a real error.' This provides clear guidance on timing and purpose, and implicitly differentiates from operations on Canvas content (courses, modules, etc.).

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 destructiveHint=false. The description adds valuable behavioral context: that the export is a single markdown document containing specific elements. It does not contradict annotations and adds context about output format and scope beyond the structured 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?

The description is two sentences long, front-loading the purpose and content list, followed by a use-case sentence. No unnecessary words or repetition.

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 the simple single-parameter tool and no output schema, the description adequately explains what the return value contains (markdown document with listed sections) and its intended use (archiving). It does not cover error cases or size limits, but these are minor given the overall clarity.

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?

With 100% schema description coverage (the only parameter 'course_id' is described as 'Canvas course ID'), the description does not add further parameter semantics. Baseline of 3 is appropriate since schema already handles documentation.

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 verb 'export' and resource 'course', specifies the output format ('single markdown document'), and lists the included components (details, syllabus, grade, assignments, modules, announcements). This distinguishes it from sibling tools that focus on single components.

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 provides clear context: it's a 'one-shot export' designed for archiving to Notion or notes apps. It implies use when a comprehensive snapshot is needed, but does not explicitly state when not to use it or name alternative tools for partial exports.

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 provide readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing exactly what fields are returned (description as text, dates, rubric, user's submission with score/grade). This is critical since no output schema exists, and it explains the scope and granularity of the response.

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 a single, well-structured sentence that immediately states the purpose and lists key return components. Every word adds value, making it efficient and easy to parse.

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

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

For a read-only tool with two simple parameters, the description sufficiently explains what the response contains, compensating for the lack of an output schema. It could mention that it returns only the current user's submission or potential error conditions, but it is adequate for typical use.

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% with both parameters having descriptions in the input schema. The description does not add any additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('one assignment's full details'), listing exact fields returned. It clearly distinguishes from sibling tools like canvas_list_assignments which lists assignments rather than getting details.

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 for retrieving full details of a single assignment, but does not explicitly state when to use this versus alternatives like canvas_list_assignments or how it differs from other get tools. Context is clear but lacks explicit guidance or exclusions.

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 destructiveHint=false, confirming safe read-only behavior. The description adds valuable context beyond annotations by stating that the tool does not mark the conversation as read, a key behavioral nuance. This is sufficient disclosure for this type of 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?

The description is just two sentences. The first sentence delivers the core action (read full thread), and the second adds a critical behavioral caveat. Every word is purposeful, and the information is front-loaded—no fluff 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?

The tool is straightforward with one parameter and no output schema. The description adequately explains what it does and a key side effect. While it could elaborate on return format or ordering, annotations cover safety, and the complexity is low, making this description sufficiently 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%: the single parameter conversation_id has a clear description ('Conversation ID from canvas_list_inbox'). The tool description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb-resource pair ('Read the full message thread') and clearly distinguishes the tool from siblings like canvas_list_inbox by specifying it targets a single conversation thread. The additional statement about not marking as read further clarifies its scope.

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 the tool is used after obtaining a conversation_id from canvas_list_inbox but does not explicitly state when to use it or when to prefer an alternative. No guidance on exclusions or alternative tools is provided, leaving the agent to infer context from sibling names.

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 destructiveHint=false, so the safety is clear. The description adds value by revealing that the tool returns 'full syllabus text', 'term', and 'current score', which are behavioral traits not inferable from annotations alone. No contradiction exists between description and 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?

The description is a single 19-word sentence that immediately states the tool's purpose and key contents. Every word earns its place, with no filler. The critical guidance about course_id source is front-loaded in the same 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?

Given the tool has 1 parameter, no output schema, and is a simple read operation, the description adequately covers the basics. However, it could be more complete by mentioning whether the tool returns only the current score or historical grades, and whether the syllabus text is complete or truncated. For a tool with this complexity, a 3 is reasonable but leaves some ambiguity.

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 parameter course_id has a clear schema description. The description adds minimal extra meaning beyond the schema by noting the source of course_id, which is helpful context but not essential for parameter semantics. Baseline 3 is appropriate as the schema already documents the parameter well.

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 verb 'Get' and the resource 'one course's details', and specifies the included fields: full syllabus text, term, and current score. It distinguishes this tool from siblings like canvas_list_courses by indicating it retrieves a single course's detail versus listing courses, though it doesn't explicitly differentiate from canvas_get_grades which also deals with scores.

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 tells the agent that course_id comes from canvas_list_courses, providing a clear prerequisite. However, it does not specify when to use this tool versus alternatives like canvas_read_syllabus (which is a sibling that might overlap in reading syllabus content) or when not to use it. The guidance is minimal but functional.

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 provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds minimal behavioral context beyond stating it is a read operation. It does not mention permissions, pagination, or what happens to the state, failing to add value beyond the annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for the tool's simplicity.

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?

The tool is simple (2 required params, no output schema, annotations present). The description mentions 'including replies' but lacks detail on the return structure (e.g., nested replies, author info). It is minimally adequate but leaves gaps for an agent deciding whether the output covers its needs.

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 both parameters having clear descriptions. The tool description does not add any additional meaning or context to the parameters beyond what the schema already provides. 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 clearly states the action ('Read') and the resource ('discussion topic's full thread, including replies'). It effectively distinguishes from sibling tools like 'canvas_list_discussions' (which lists topics) and other read 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?

The description implies using this tool after listing discussions, but it does not explicitly state when to use it versus alternatives (e.g., 'canvas_list_discussions' for summaries). No when-not-to-use guidance or prerequisites are 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?

The annotations already indicate readOnlyHint is true, so the description does not need to restate safety. The description adds value by clarifying the tool excludes submissions without feedback or grade (unless include_empty is used), which is behavioral nuance beyond the annotations. No contradiction with annotations.

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

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

Description is two sentences that front-load the primary purpose, each sentence earning its place. First sentence states the core function, second adds key usage detail. No fluff.

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?

The tool is relatively simple with only 2 optional parameters and no output schema. The description covers the main behavior (returns feedback-holding submissions) and the default for course_id. It would be more complete if it mentioned that the tool only applies to graded submissions, but for a read-only list tool with good annotations and clear schema, it suffices.

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 description does not need to redefine parameters. However, the description does not add any extra context beyond what the schema already provides for course_id and include_empty, producing a baseline score of 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?

The description clearly states the tool retrieves grader comments and rubric assessments, which distinguishes it from other tools in the sibling list like `canvas_get_grades` or `canvas_list_todo`. The verb 'get' and the resource 'feedback on submissions' are specific and unambiguous.

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

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

The description explicitly explains when to omit the course_id parameter to check every active course, and notes that only submissions with feedback or a grade are returned. However, it does not exclude when not to use it (e.g., when only grade totals are needed) nor mention alternatives like `canvas_get_grades` which could be a sibling for grade-related needs.

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 destructiveHint=false, so the behavior as a safe read operation is clear. The description adds that the URL is temporary and expires, which is useful beyond what annotations provide. It doesn't describe rate limits or auth requirements, but these are minor for a simple read tool.

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

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

Two sentences, zero wasted words. The first sentence states the action and source of the ID, the second provides a critical usage note about expiration. 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?

Given the tool has only 1 parameter, good annotations, and no output schema, the description covers the essential behavioral aspects. The temporary nature of the URL is important and disclosed. It could mention the return format (URL string) slightly more explicitly, but it's clear enough.

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%. The description mentions the source of the file_id (canvas_list_files or module items), which adds slight context beyond the schema's 'Canvas file ID'. However, the schema itself already handles the parameter definition adequately.

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 uses the specific verb 'Get' and the resource 'temporary authenticated download URL for a file'. It clearly distinguishes this tool from siblings like canvas_list_files (which lists files) and canvas_read_file (which likely reads file content directly). The description immediately identifies the purpose and the expected input.

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 explicitly states that the 'file_id' comes from 'canvas_list_files or module items', giving clear usage context. It also notes the URL expires and to use it promptly, which implies when to download the file. However, it does not explain when NOT to use this tool versus alternatives like canvas_read_file or canvas_export_course.

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 provide readOnlyHint:true and destructiveHint:false, so the description doesn't need to reiterate safety. It adds useful behavioral context about the two modes and the return fields. However, it does not mention pagination behavior, rate limits, or what happens if a course has no graded submissions — these are minor gaps that prevent a higher score.

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

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

The description is only two sentences, front-loading the most important behavioral distinction. Every sentence adds value. It could be slightly more concise by removing the trailing em-dash phrase but overall is efficient.

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 the tool has only one optional parameter, full schema coverage, and readOnlyHint/true, the description covers the core behavior well. No output schema exists, but the description explains what fields are returned (assignment name, score, points possible, flags). A small improvement would be noting if results are paginated or sorted.

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 meaning by explaining the behavioral difference between providing course_id (detailed breakdown) vs. omitting it (overview). This semantic distinction goes beyond the schema's description and justifies a 4.

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 a specific verb ('get') and two distinct resources depending on whether course_id is provided: current score/grade for active courses, or graded submissions with assignment name, score, points possible, and flags. It distinguishes itself from siblings like canvas_grade_breakdown by explaining the different granularity.

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 explicitly tells when to use each variant (without course_id vs. with course_id) and provides a concrete use case ('what's my grade breakdown'). However, it does not explicitly state when not to use it or name alternative tools for similar needs, 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 and destructiveHint=false. The description adds behavioral traits beyond annotations by detailing the specific output structure (module states, item requirements, completion status). No contradictions exist.

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, well-structured sentence that front-loads the core purpose ('Show module-by-module progress') and efficiently packs all key details about states and requirements without any waste.

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?

The description adequately explains the return value structure (module states, per-item requirements and completion) despite no output schema. It covers the main aspects an agent needs to understand the tool's output, though it does not specify the exact hierarchical format.

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?

Input schema has 100% description coverage, with clear descriptions for course_id and incomplete_only. The tool description adds no extra meaning for the parameters beyond what the schema provides; it describes the output instead. 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 clearly states it shows module-by-module progress including states (locked/started/completed) and per-item requirements (view/submit/contribute/score) with completion status. This distinguishes it from the sibling canvas_list_modules which only lists modules without progress details.

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 when to use this tool—when module-level progress and per-item requirements are needed. It doesn't explicitly exclude alternatives or state when not to use it, but the context is clear given sibling tools.

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 provide readOnlyHint: true and destructiveHint: false, so the description adds value by specifying the output format ('full content as text'). It does not repeat annotation info and adds unique context. There is no contradiction with annotations.

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

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

The description is extremely concise: two sentences with no excess words. Every sentence adds value—the first explains the core action and output, the second clarifies the parameter source. No redundancy or 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?

Given the tool has a simple read operation, 100% schema coverage, no output schema, and strong annotations, the description is complete. It tells the agent what it does, what the output is, and where to get the parameter. No additional context is needed 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 both parameters well. The description adds minimal semantic value beyond the schema: it clarifies that page_url is a 'slug' from other tools, which is useful context. Baseline 3 is appropriate as the description adds marginal but helpful 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?

The description clearly states the tool reads a course page's full content as text, using a specific verb ('Read') and resource ('course page'). It distinguishes itself from siblings like canvas_list_pages (which likely lists pages without content) and canvas_list_modules (which lists modules). However, it could be more explicit about the distinction from sibling tools.

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

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

The description tells users to use the 'url' slug from canvas_list_pages or canvas_list_modules as the page_url, providing clear context on how to obtain the parameter value. It does not explicitly state when not to use this tool or mention alternatives, but the sibling list and the instruction to read rather than list implicitly guide usage.

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 destructiveHint=false, so the description's main behavioral contribution is specifying the returned fields. It adds no details about authentication scope, rate limits, or error behaviors, but for a simple read-only profile fetch, this is acceptable. No contradictions with annotations.

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

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

The description consists of two short sentences with no wasted words. The action and output are front-loaded, making it immediately scannable. Every sentence serves a purpose: stating what it does and providing a usage hint.

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 the tool has no parameters, no output schema, and low complexity, the description fully covers the purpose, usage context, and output format. It is complete for an agent to understand and invoke the 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?

There are zero parameters, and the schema description coverage is 100%. Per the guidelines, zero parameters warrant a baseline of 4. The description implicitly confirms no parameters are needed, which adds no new meaning but aligns with expected behavior.

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 uses the specific verb 'Fetch' with the resource 'Canvas profile' and lists the returned fields (name, primary email, id). It clearly distinguishes this tool from siblings like canvas_auth_status or canvas_list_courses by focusing specifically on the authenticated user's own profile.

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 explicitly states one primary use case: 'Use this to verify the API token works.' This gives clear guidance on when to apply the tool. It does not mention when not to use it or suggest alternatives, but given the tool's simplicity, the provided guidance is sufficient.

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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds value beyond annotations by disclosing the behavioral trait that it shows 'what's graded, what's left, and your current standing' and that passing target_grade triggers a computation. No contradictions with annotations.

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

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

Two sentences, no wasted words. The first sentence front-loads the core purpose, and the second sentence precisely explains the optional parameter. 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?

Given the tool's moderate complexity (2 params, no output schema, no nested objects), the description is nearly complete. It explains the breakdown, the what-if feature, and the parameter semantics. However, it doesn't describe the return format (e.g., whether it returns per-group details or just a summary), which could be useful for the agent. Still, without an output schema, the description covers the main expectations well.

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 both parameters. The description adds meaning by explaining that `target_grade` is optional and used for the what-if calculation ('compute the average you need on all remaining work'), which is not in the schema. The `course_id` parameter is standard and needs no elaboration.

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 uses a specific verb ('break down') and clearly identifies the resource ('course grade by assignment group') and the tool's dual functionality: showing current standing and computing what-if scenarios. This distinguishes it from siblings like canvas_get_grades, which likely just returns a number, and canvas_list_assignments, which lists items without grade breakdown.

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 explicitly states when to use the `target_grade` parameter ('Pass target_grade... to compute the average you need'), providing clear guidance for the what-if use case. However, it does not explicitly state when NOT to use this tool (e.g., if you only need a single numerical grade, use canvas_get_grades instead), leaving some ambiguity for the agent.

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 destructiveHint=false, so the tool is clearly read-only and non-destructive. The description adds behavioral context that the default time window is 30 days and that it applies to active courses, which is useful 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?

The description is a single, concise sentence that front-loads the purpose and immediately adds crucial default and customization details. Every word is necessary and there is no fluff.

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 that there is no output schema and no required parameters, the description adequately explains inputs and defaults. It could optionally mention that the result is a list of announcement objects, but for a low-complexity read-only tool, it is sufficiently complete to inform an agent.

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 adds value by explaining the default behavior for start_date (30 days ago) and end_date (today), and connecting course_id to limiting by course. This goes beyond the schema's brief parameter descriptions.

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 'List announcements' and specifies the scope: 'Defaults to all active courses over the last 30 days', with options to narrow or widen via course_id and start_date. This differentiates it from sibling tools like canvas_list_modules or canvas_list_discussions.

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 provides context for when to use this tool: when listing announcements with default scope or custom filtering by course or date range. However, it does not explicitly mention when not to use it or how it compares to other list tools like canvas_list_inbox or canvas_get_feedback.

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, openWorldHint=true, and destructiveHint=false, so the tool is safe and non-destructive. The description adds value by specifying ordering ('by due date') and the inclusion of submission status, which goes beyond what annotations provide.

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

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

The description is two sentences, front-loads the core purpose, and adds bucket filters concisely. Every sentence earns its place with no redundancy.

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

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

Given the tool's simplicity (2 parameters, no output schema, read-only), the description is complete enough. It covers what is listed, ordering, and filtering options. A minor gap is the lack of mention of pagination or return format, but for a list tool this is acceptable.

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 fully documents both parameters. The description adds no additional meaning beyond the schema, but it does list the enum values explicitly in the description text, reinforcing the options. 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 uses specific verbs ('list') and resources ('assignments' with 'submission status'), and distinguishes from siblings like 'canvas_get_assignment' (single) and 'canvas_list_todo' (different scope). It clearly states ordering by due date and includes submission details.

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 lists optional bucket filters for common use cases, which helps an agent decide when to apply them. However, it does not explicitly state when to use this tool versus alternatives like 'canvas_list_todo' or 'canvas_get_assignment'.

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 clearly mark readOnlyHint and destructiveHint false, so the description doesn't need to reiterate safety. The description adds value by revealing that the tool can produce two different data shapes (events vs. assignments) and that it aggregates all courses. This contextualizes the 'openWorldHint' annotation by showing the scope filtering per course.

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 two sentences long, front-loads the core purpose (list events between dates), and adds one valuable nuance about the type parameter. Every word contributes meaning; there is no repetition of schema or annotation data.

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?

The tool has 4 parameters (all described in schema), no output schema, and moderate complexity (two event types, optional course filter). The description explains the key variant (assignment type) and default behavior (all courses). However, it does not mention the response format or pagination, which might be needed for completeness given no output schema, but this is a minor gap for a read-only list 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 coverage is 100%, so the schema already documents all parameters with types and descriptions. The description adds only minor semantics: clarifying that 'type=assignment' yields assignment due dates (while the schema enum just lists 'assignment') and that course_id limits to one course (vs. default all). This enriches the schema but is not extensive.

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 lists calendar events between dates, specifying types like lectures, office hours, deadlines. It distinguishes itself from siblings by noting that 'type=assignment' shows assignment due dates, which is unique among the sibling tools (e.g., canvas_list_assignments likely lists assignments differently, not as calendar events).

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 implicitly suggests using 'type=assignment' for due dates but does not explicitly state when to use this tool over alternatives like canvas_list_assignments or canvas_list_todo. It lacks guidance on prerequisites (e.g., course enrollment, tool auth) and does not mention when not to use it.

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

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

Annotations already declare `readOnlyHint=true` and `destructiveHint=false`, making the non-mutating behavior clear. The description adds crucial behavioral context by specifying the default `state` behavior ('active' by default) and the scope of included data (current score/grade). A small gap remains: it doesn't explicitly state that results are scoped to the authenticated user (implied by 'my courses' in the title), but the combination of title, description, and annotations is strong.

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 two sentences long with zero wasted words. The first sentence establishes purpose and key feature (score/grade), the second sentence clearly explains the parameter's behavioral effect. 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?

Given the tool's low complexity (1 optional param, no output schema) and the richness of annotations and schema coverage, the description is largely complete. It explains the filter behavior and default clearly. The only minor gap is lacking explicit mention of the return format (e.g., pagination or structure), but this is acceptable for a simple list tool with no output schema and a strong title.

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 schema already documents the parameter and its enum values. The description adds significant meaning by explaining the real-world mapping of each enum value ('this semester', 'past courses', 'everything'), which is not present in the schema's generic 'Enrollment state filter' description. This goes beyond the schema baseline of 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?

The description provides a specific verb ('List'), a clear resource ('the user's Canvas courses'), and the unique value ('with current score/grade per course'). It distinguishes this tool from the sibling `canvas_list_modules`, `canvas_get_course`, and `canvas_get_grades` by bundling score display with the list, making its purpose immediately obvious and distinct.

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 explicitly tells the agent when to use which filter: `state='active'` for the current semester, `state='completed'` for past courses, and `state='all'` for everything. This provides clear context and exclusions (e.g., not for a specific course detail, which belongs to `canvas_get_course`), and implicitly guides against misuse.

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 destructiveHint=false, so the description adds value by disclosing that the response includes 'unread counts and due dates'. However, it omits other behavioral traits such as pagination, ordering, or filtering capabilities. The added context is moderate.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose and key output details. No superfluous words or repetition. Every word earns its place.

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

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

For a simple list tool with one parameter, annotations, and no output schema, the description adequately covers the purpose and key output fields. It hints at the response structure (topics with unread counts and due dates). However, it could mention pagination or sorting if applicable, but given the tool's simplicity, it is mostly 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 coverage is 100% with the sole parameter 'course_id' described as 'Canvas course ID'. The description does not add any new meaning beyond the schema, such as format, constraints, or examples. With high coverage, 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 clearly states the verb 'List' and the resource 'discussion topics' with specific additional information ('unread counts and due dates'). This distinguishes it from sibling tools like canvas_list_assignments or canvas_list_announcements, which list different resources. The scope is implied by the course_id parameter.

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 provides no guidance on when to use this tool versus alternatives (e.g., canvas_get_discussion for a single discussion). It does not state when not to use it or mention any prerequisites. The agent must infer usage from context alone.

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 indicate readOnlyHint=true and destructiveHint=false, so the core safety profile is covered. The description adds that the tool returns file IDs for canvas_get_file_link, which is useful for chaining. However, it does not disclose pagination, sorting, or whether all files are returned at once.

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 two concise sentences with no wasted words. It front-loads the primary purpose and immediately adds a practical usage detail (filtering by name) and a note about return value usage.

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 the tool's simplicity (two parameters, no output schema), the description is largely complete. It covers the action, scope, filtering, and intended downstream usage. A minor gap is the lack of information on pagination or result limits, but this is not critical for a list tool with open world hint.

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 fully documents both parameters (course_id and search_term). The description adds no new semantic detail beyond what the schema provides, earning the baseline score.

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 explicitly states the tool lists files in a course, specifies common file types (slides, PDFs, handouts), and distinguishes it from siblings like canvas_list_modules or canvas_read_file by focusing on file enumeration and retrieval of file IDs for use with canvas_get_file_link.

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 explains when to use the tool (listing course files) and how to filter with search_term, but does not explicitly state when not to use it or mention alternatives among the many sibling tools.

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, openWorldHint=true, and destructiveHint=false, so the description's role is reduced. It adds the scope detail (user's groups, not all groups) but doesn't mention pagination, sorting, or any behavioral traits 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?

A single, concise sentence that front-loads the key information with zero waste.

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, parameterless, read-only tool with complete annotations, the description is sufficient. No output schema exists but the return values are implied. Could mention if results are filtered by user (already implied by 'you belong to').

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% with zero parameters, so there is nothing to add. Baseline 3 plus 1 for complete clarity.

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 uses a specific verb ('List') and resource ('Canvas groups'), and clarifies the scope ('you belong to') and content ('project teams, study groups, sections') with member counts and course. It clearly distinguishes from siblings which list different entities (courses, assignments, etc.).

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?

Implied usage is clear but no guidance on when not to use it or alternatives. With many siblings, explicit differentiation would help but the scope note partially addresses 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns sender, course, preview, and read state, which is useful but does not disclose pagination behavior or rate limits. Given good annotations, the bar is lower, and the description adds moderate 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?

Two sentences with no wasted words. The first sentence states the core function and output fields; the second provides actionable usage guidance. 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?

Given only 2 optional parameters, no output schema (so the description doesn't need to document return fields beyond what it states), and strong annotations, this description is complete enough. It covers purpose, output fields, and usage guidance for the key filter. Could mention pagination or limit defaults but not strictly necessary for this simple 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 coverage is 100%, so the schema already documents both parameters (limit, scope) with descriptions and enums. The description adds marginal meaning by suggesting a common scope value ('unread'), but this is a minor enhancement. 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 uses a specific verb ('List') and resource ('Canvas inbox messages'), and clarifies what the messages contain (sender, course, preview, read state). It distinguishes from siblings like canvas_list_announcements or canvas_list_discussions by explicitly naming the 'Canvas inbox' context.

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 provides explicit usage guidance for the scope parameter ('Use scope='unread' for just unread messages'), which helps the agent decide when to filter. However, it doesn't mention when not to use this tool or compare it directly to siblings like canvas_get_conversation for reading individual messages.

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, openWorldHint=true, and destructiveHint=false. The description adds value beyond these by specifying that the output includes items in order and represents the content outline. This provides useful behavioral context without contradicting 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?

The description is a single, well-structured sentence that is front-loaded with the core action and resource. Every word adds value, with no redundancy or filler. It is concise yet informative.

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 the absence of an output schema, the description reasonably explains the return value: a list of modules with items, in order, representing the course outline. This is sufficient for an open-world read tool, though it could briefly mention the structure of module objects. Overall, it is complete enough for the tool's complexity.

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 has 100% description coverage for the single parameter 'course_id', which is adequately described as 'Canvas course ID'. The tool description does not add any additional semantics or usage notes for the parameter, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List', the resource 'a course's modules', and specifies what is included ('their items (pages, files, assignments, quizzes, links) in order'). It also provides a concise summary ('the course's content outline'), which distinguishes it from sibling tools like canvas_list_assignments or canvas_list_courses.

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 the tool is for retrieving the course content outline, but it does not explicitly state when to use this tool versus alternatives (e.g., canvas_get_module_progress for progress, or canvas_list_assignments for assignments). No when-not or exclusion criteria are provided, leaving the agent to infer usage context.

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

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

Annotations include readOnlyHint=true and destructiveHint=false, which already cover safety. The description adds no behavioral detail beyond that, such as pagination, rate limits, or that it lists all pages by default. Since annotations provide the core safety profile, a score of 3 is appropriate as the description adds minimal extra context.

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

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

The description is concise with two sentences, front-loaded with the main action and then the filter detail. No wasted words. It earns a high score for brevity, but could be slightly more informative without harming conciseness.

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 the tool's simplicity (list operation with 2 params) and the strong annotations covering safety, the description is adequate. It doesn't explain the return format, but no output schema exists, so the agent might need to infer that. For a simple list tool, this is acceptable but leaves room for improvement.

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 parameters have descriptions. The description mentions that search_term filters by title, which adds some semantic value beyond the schema's 'Filter pages by title'. However, it doesn't add new meaning for course_id. Baseline 3 is justified since the schema does the heavy lifting.

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

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

The description clearly states the function: list a course's wiki pages. It includes the resource ('wiki pages') and the course scope, which differentiates it from sibling tools like canvas_list_modules or canvas_get_page. However, it doesn't explicitly mention that it returns a list (as opposed to a single page), but the verb 'list' implies that.

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 for listing pages and mentions the optional search_term filter, but it does not explicitly state when to use this tool versus canvas_get_page or other list tools. There is no mention of when not to use it or alternatives, but given the clear purpose, the usage context is reasonably implied.

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 explains that the tool scans the course's peer-review assignments and returns status, which aligns with the readOnlyHint=true annotation. It adds behavioral context beyond the schema (e.g., scanning behavior). However, it does not address the openWorldHint annotation, nor does it mention potential performance implications of scanning. The description is adequate but does not fully explore side effects or return structure.

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 extremely concise, consisting of two well-constructed sentences. The first sentence fronts the purpose and what the user gets (status), and the second sentence explains parameter usage. Every word is necessary; there is no redundancy or 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?

Given a simple list tool with no output schema, the description covers the essential aspects: what it does (find peer reviews), scope (course-wide or single assignment), and status information. It could be slightly more complete by explicitly stating the output format (e.g., list of peer reviews with status fields) but remains nearly complete for the tool's complexity.

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

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

The input schema has 100% coverage with descriptions for both course_id and assignment_id. The description adds value by contextualizing the parameters: it explains that scanning the course is the default behavior and that assignment_id allows focusing on a single assignment. This enhances the schema's bare parameter descriptions by clarifying the operational difference.

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 finds peer reviews assigned to the user and their status, using specific verbs and resources ('Find peer reviews you've been asked to complete, and their status'). It distinguishes between scanning an entire course and checking a single assignment via the assignment_id parameter, which differentiates it from siblings like canvas_list_assignments or canvas_get_assignment.

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 provides clear context on when to use the tool: to find peer reviews you need to complete. It also specifies an alternative usage by passing assignment_id to check just one assignment instead of scanning the course. However, it does not explicitly mention when not to use the tool (e.g., against listing all assignments or checking grades), leaving the exclusion implicit.

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 adds context about the items being 'flagged with whether it has new activity and your submission state' and mentions date ordering, which goes beyond the annotations (which already confirm it is read-only, non-destructive, and open-world). No contradictions found.

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 a single sentence with essential details; it is front-loaded with the core function. The sibling reference adds a touch of extra context without being verbose. One could argue it is slightly dense but still efficient.

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 there is no output schema, the description reasonably covers return contents (item types and flags). With 3 optional parameters and clear annotations, the description is sufficient for a read-only listing tool. No major gaps are evident.

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?

All 3 parameters have descriptions in the schema, so schema coverage is 100%. The description does not add further parameter info, so a baseline score of 3 is appropriate as the schema already 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?

The description states a specific verb ('list') and resource ('Planner feed across all courses') and lists included item types. It distinguishes itself from the sibling 'canvas_list_todo' by stating it is 'Richer', providing clear differentiation.

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

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

The description implies when to use this tool (for a comprehensive planner view including new activity and submission states) and hints at an alternative (the simpler 'canvas_list_todo'), but could be more explicit about when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds value by specifying the exact fields returned (due dates, time limits, allowed attempts, points), which is not captured by annotations. No contradiction with annotations.

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

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

The description is a single sentence that is front-loaded with the action (list) and resource (quizzes). Every word is purposeful, with no fluff. It is optimally concise.

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 list tool with one required parameter and no output schema, the description is reasonably complete. It specifies the returned fields. However, it omits details like pagination, ordering, or filtering, which might be expected for a list operation. Still, given the tool's simplicity, it covers the essential information.

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% with one parameter (course_id) already described as 'Canvas course ID'. The description does not add any additional meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'list' and the resource 'quizzes' scoped to a course. It also specifies the fields returned (due dates, time limits, allowed attempts, points), which distinguishes it from sibling tools like canvas_list_assignments or canvas_list_modules.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, filtering options, or when not to use it. The agent must infer usage from context alone.

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 provide readOnlyHint=true and destructiveHint=false. The description adds that the list includes only items needing submission, which is specific context. However, it does not disclose what happens when there are no items, how results are ordered, or any pagination behavior. Given the tool has zero parameters, the description adds modest value beyond annotations.

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

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

One sentence that immediately identifies the resource ('user's Canvas to-do list') and its scope ('across all courses'). No wasted words.

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 zero parameters, no output schema, and adequate annotations, the description is largely complete. It states what is returned (assignments and quizzes needing submission). It could be improved by clarifying ordering or the criteria for 'needing submission', but it is sufficient for a simple list endpoint.

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 tool has zero parameters, so baseline is 4. The description adds no parameter details, but none are needed since the schema already fully covers the lack of inputs.

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 returns the user's to-do list consisting of assignments and quizzes needing submission across all courses. It distinguishes from siblings like canvas_list_assignments (all assignments) and canvas_list_quizzes (all quizzes) by focusing on items requiring 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?

The description provides no guidance on when to use this tool versus alternatives like canvas_list_assignments or canvas_list_upcoming. It does not mention when not to use it or any 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, openWorldHint=true, and destructiveHint=false. The description reinforces these by stating it's a non-destructive read ('upcoming events and assignment due dates'). It adds value beyond annotations by clarifying the temporal scope ('next ~2 weeks') and the fact it spans all courses, which openWorldHint alone does not specify.

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 a single sentence of 12 words, front-loaded with the key verb and resource. Every word earns its place ('upcoming', 'Canvas events and assignment due dates', 'across all courses', 'next ~2 weeks'). No redundancy or 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?

Given zero parameters, no output schema, and rich annotations, the description is nearly complete. It explains what the tool returns, its scope ('across all courses'), and its time window ('next ~2 weeks'). One could argue for clarifying the return format (e.g., 'returns a list of events with dates'), but the lack of output schema makes this less critical. The essential context is well 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% with zero parameters, so there are no parameters to document. The description adds no parameter info, but the baseline is 4 for zero-param tools. It could briefly hint at the output format or time window, but the high coverage already means the schema is fully handled.

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 uses a specific verb ('upcoming') and resource ('Canvas events and assignment due dates') with clear scope ('across all courses, next ~2 weeks'). It distinguishes this tool from siblings like canvas_list_assignments (which lacks the global upcoming view), canvas_list_todo (which may have a different scope), and canvas_list_calendar_events (which is broader). The scope and resource are precisely defined.

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?

Although no explicit when-not-to-use or alternative is named, the description clearly states the scope ('across all courses' and 'next ~2 weeks'), which implicitly guides the agent: use this for a consolidated upcoming view over a limited horizon; for a single course's assignments or full calendar, use sibling tools. In context of zero-parameter tool, the explicit scope is sufficient without needing more detail.

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 destructiveHint=false, so the description's main behavioral value is confirming it's non-destructive reading. The description adds key behavioral context: it can process multiple document formats (PDF, .docx, .pptx, .xlsx, HTML, plain text) and it extracts text from those files. It does not mention file size limits or supported character encodings, but for a file-read tool with good annotation coverage, this is sufficient. No contradiction with annotations.

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

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

Three sentences, zero wasted words. The first sentence states what the tool does and its supported formats. The second sentence gives concrete use cases. The third sentence tells the agent where to find the required parameter value. Every sentence serves a distinct purpose, and the most actionable information is front-loaded.

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 the tool's moderate complexity (2 params, no nested objects, no output schema), the description covers purpose, usage, and parameter source well. It does not explain expected return format (the extracted text and possibly metadata), but since no output schema exists, the agent would benefit from that. However, by listing file formats and extraction behavior, the agent can reasonably infer the output shape. A minor gap given the tool's simplicity.

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 (file_id, max_chars) are already documented in the schema. The description adds value by specifying that file_id comes from specific sources (canvas_list_files or module item's content_id), which clarifies the data dependency. The max_chars parameter is not mentioned in the description, but since the schema already provides a clear description, description coverage is acceptable.

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 uses clear verb-resource pairing: 'Download a Canvas file and extract its text', immediately stating the core purpose. It lists supported formats (PDF, Word, etc.) and concrete use cases (syllabi, lecture slides, handouts), leaving no ambiguity. Among siblings like canvas_get_file_link (which just returns a URL) and canvas_read_syllabus (which reads a specific syllabus), this tool is distinctly positioned as the generic text-extraction tool for any file.

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 explicitly tells the agent when to use this tool ('Use this to read syllabi, lecture slides, and handouts') and tells it where to get the file_id ('file_id comes from canvas_list_files or a module item's content_id'), which is critical since the agent might otherwise not know how to obtain a valid file_id. It does not provide when-not-to-use guidance, but for a read-only extraction tool with clear purpose, the positive guidance suffices.

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 mark the tool as read-only and non-destructive. The description adds value by revealing that when the syllabus is an attached file (PDF/Word), the tool performs download and text extraction. This behavioral detail is not inferable from annotations alone.

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 two sentences with zero wasted words. The first sentence states the primary purpose, and the second efficiently adds nuance about handling two syllabus formats and the extraction process. It is front-loaded and well-structured.

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?

The description lacks details about the return format (e.g., plain text vs. Markdown) and does not mention error cases like missing syllabus. Given the tool's low complexity and the presence of annotations, it is minimally complete but leaves some gaps for an agent.

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%—the input schema already describes both parameters (course_id and max_chars) adequately. The description adds no extra semantic value about the parameters, so a baseline score of 3 is appropriate.

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

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

The description clearly specifies the action 'Get' and the resource 'course's syllabus as text'. It distinguishes itself from siblings by explicitly stating that it handles both inline syllabus text and attached PDF/Word files, which is a unique capability among the listed tools.

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 by covering both common syllabus formats, but it does not explicitly state when to use this tool versus alternatives like canvas_read_file or other content retrieval tools. There are no exclusions or comparative guidance.

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