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

Annotations already cover read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description still adds real context: ISO dates with an explicit offset are required, calendar calls cap at ten contexts, planner data is not a complete timetable, and each source reports its own completeness/errors instead of silently failing.

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?

Short and front-loaded: the main capability comes first, followed by format requirements, a limit, and a caveat. The telegraphic, fragment-heavy phrasing costs a little readability but nearly every sentence carries information.

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

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

A read-only, annotated tool with an output schema needs less return-value explanation, and the description supplies the key caveats an agent would otherwise miss: date formatting, batch limits, incomplete planner coverage, and per-source error reporting. Only the course_ids-omitted behavior is left implicit.

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 0%, so the description must carry the parameter burden. It clarifies date format (ISO with explicit offset) and that course_ids gates calendar/assignment retrieval, which adds value. It does not explain the course_ids format, the null default (planner-only), or the array-of-strings shape, leaving gaps.

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

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

States a specific verb (read) and names the three resources it spans: planner work, calendar events, and assignment dates. The sibling set includes canvas_assignments and canvas_courses, and the description implies this tool is the cross-source agenda view rather than a single-resource reader, though it never names that distinction explicitly.

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

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

"For explicit course IDs" and "Planner alone is not a complete institutional timetable" imply when each source applies, and the ten-context batch limit hints at chunking. But there is no explicit statement of when to use this tool versus canvas_assignments or canvas_courses, and no guidance on what happens when course_ids is omitted.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description contributes the meaningful scoping detail that only the caller's own submission metadata is returned, not the whole class's. It says nothing about pagination behavior despite a max_pages cap of 20, which is real behavioral information an agent would want.

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

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

A single front-loaded sentence with no filler; the verb comes first and the returned fields follow. It is efficient but so terse that the list of fields substitutes for actual guidance.

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

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

An output schema exists, so return shape need not be spelled out, and annotations cover safety. The remaining gaps are the undocumented pagination parameter and the unresolved ambiguity with canvas_submission, which the description leaves an agent to guess at.

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 0%, so the description must carry the load and it does not: neither course_id nor max_pages is mentioned. max_pages in particular controls how many pages of assignments are fetched (up to 20), and the description gives no hint that results may be truncated or how to retrieve more.

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 pairs a specific verb ('Read') with a specific resource ('assignment') and enumerates the payload it exposes: instructions, due dates, points, and own submission metadata. That is enough for an agent to know what it retrieves, though it never contrasts itself with canvas_submission or canvas_read, which overlap on the submission-data angle.

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

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

There is no when-to-use statement, no prerequisite framing, and no routing to alternatives. An agent cannot tell from this text whether to call canvas_assignments or canvas_submission when it needs submission state, since the description claims to expose 'own submission metadata' without clarifying the boundary.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and liveness profile is covered by structured data. The description adds only the access scoping ('accessible to you'); it says nothing about pagination volume, how many pages it will traverse, or whether results are truncated.

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

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

Two short sentences, no filler, with the core purpose front-loaded and the routing hint immediately after. Every clause carries information an agent needs.

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

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

An output schema exists, so return-value detail is legitimately omitted, and annotations cover the safety profile. However, for a paginated listing tool with a max_pages control the agent has to guess about, the description is under-specified on result volume and page traversal behavior.

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 0%: the single parameter max_pages (default 1, max 20) has no description in the schema and is never mentioned in the tool description. The description therefore fails to compensate for the coverage gap, leaving the agent to infer that max_pages controls pagination depth and that the default returns only the first page of courses.

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

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

States a specific verb and resource ('List courses accessible to you') with a scope qualifier (accessible to you) that implies it is an enrollment-scoped listing. It names one sibling, canvas_read, as the alternative for filtering, so an agent can distinguish it from the filter-oriented path, though it does not differentiate itself from canvas_discover or canvas_outline.

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

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

Explicitly routes the agent: for enrollment/state filtering, use canvas_read instead. That is a clear alternative with a condition that selects it. It stops short of stating exclusions in the other direction (e.g. when canvas_discover or canvas_outline is preferred), so it is not a full when/when-not matrix.

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 readOnly, idempotent, non-destructive, openWorld. The description adds genuinely new context beyond those: only 'reviewed' operations are surfaced, and permissions/OAuth scopes still apply to the discovered operations. That auth caveat is valuable behavioral information the agent wouldn't otherwise know. Return shape is covered by the output schema, so no penalty there.

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

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

Three short lines with no wasted words, and the core purpose leads. The opening sentence is a bit dense/abstract but the following lines quickly ground it with examples and workflow. Efficient overall.

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 low-complexity, single-parameter discovery tool with an output schema, the description supplies purpose, example queries, and the downstream handoff to canvas_read. The only meaningful omission is how search matching behaves, which is minor given the schema and output schema already present.

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 0%, so the description must carry the load for the single 'search' parameter. It does so with a list of example queries (submission, rubric, discussion, file, quiz, calendar), giving the agent a real sense of expected values. It doesn't specify matching semantics (substring vs. keyword), which keeps it at 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 states a concrete verb+resource: it finds reviewed read operations along with their required path parameters and accepted query keys, and clarifies that IDs feed into canvas_read. It distinguishes itself from the sibling execution tools (canvas_read, canvas_courses) by being explicitly a discovery/index tool. It's slightly abstract about what 'reviewed read operations' means in practice, keeping it from a 5.

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

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

It gives concrete search-term examples (submission, rubric, discussion, file, quiz, calendar) and states the downstream workflow: 'IDs are passed to canvas_read.' That is clear usage context. It stops short of explicitly saying when NOT to use it (e.g., 'don't call this if you already know the operation'), so it isn't 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 cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds real context beyond them: content is bounded, signed download URLs are deliberately excluded, and attachment content must never be executed. It stops short of explaining what happens on truncation when the bound is hit.

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

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

Four short lines, front-loaded with the core read-then-return-format statement. No filler, though the 'Never execute attachment content' safety note could arguably sit closer to the return-format 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?

With an output schema present, the description doesn't need to enumerate return fields, and it covers the key client-facing concerns (text vs base64, URL omission, size bound, CLI escape hatch). The remaining gap is truncation semantics when max_bytes is exceeded.

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 0%, so the description carries the burden and only 'bounded content' gestures at max_bytes, without stating units, truncation behavior, or the 500000 cap. The required file_id parameter gets no meaning beyond its name.

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

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

States a specific verb and resource: 'Read a Canvas attachment by ID', and immediately enumerates what comes back (bounded content, MIME type, SHA-256). The attachment/file resource is distinguishable from text-oriented siblings like canvas_read, though no sibling is named explicitly.

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

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

Gives conditional routing guidance: text comes back directly, binary comes back as base64 for a capable client, and larger files should be exported locally with the CLI. That is clear when-this-vs-alternative context, though it never contrasts with canvas_read or canvas_outline for attachment-adjacent cases.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: it warns that inline items may be incomplete and explains the follow-up call needed to get complete data via the per-module paginated endpoint.

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

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

Two tight sentences with the primary purpose front-loaded and the pagination caveat immediately after. The completion-marking-UI clause is slightly cryptic but earns its place as an exclusion.

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

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

An output schema exists, so return values needn't be described, and annotations cover safety behavior. The key behavioral gap an agent would hit (incomplete inline items) is disclosed, leaving only minor gaps like course_id semantics.

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 0%, so the description must compensate. It explains module_id well (selects one module's items, triggers the paginated endpoint) but leaves course_id entirely undocumented beyond its name. Partial compensation merits a mid 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?

States a specific verb and resource: 'List modules, or all items in one module,' which is clearly distinct from sibling tools like canvas_courses or canvas_assignments. It doesn't explicitly name the sibling it replaces, but the resource scope is unambiguous.

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

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

Gives a clear when-not ('do not navigate completion-marking UI URLs') and a procedural disambiguation: call again with module_id to reach the paginated items endpoint. No sibling alternative is named explicitly, keeping it below 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 readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds real behavior beyond that: one page is the default, pagination metadata is preserved, a false 'complete' flag signals more data or an error, and mutations/unknown paths are rejected by policy.

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

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

Front-loads purpose in the first sentence, then packs syntax and pagination guidance into a few compact lines with no filler. A phrase like 'a false complete flag means more data or an error' is dense but 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?

Output schema exists, so return values needn't be spelled out, and the description still covers the key non-obvious return signal (the 'complete' flag) and pagination. Combined with annotation coverage and path/query syntax guidance, an agent has what it needs to call this 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?

With 0% schema description coverage, the description carries the burden well: it shows explicit path syntax ({course_id: '101'}), explains query array keys like include[] with list values, and notes one page is the default (mapping to max_pages). The 'operation' parameter is only indirectly explained as a discovered operation, leaving a small gap.

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

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

States a specific verb (read) plus the resource (a 'discovered operation'), tying it to canvas_discover and distinguishing it from fixed-resource siblings like canvas_courses. The abstraction 'discovered operation' is a bit generic, but an agent can tell this is the generic operation executor versus the dedicated endpoint 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?

Provides clear context: it operates on operations surfaced by discovery, requires explicit path values, and rejects read-state mutations and unknown paths/queries. It doesn't explicitly name when to prefer canvas_courses or canvas_assignments over this generic reader, so it stops short of full when/when-not/alternatives coverage.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by explicitly stating it does not mark the submission as read, which is a meaningful side-effect clarification 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 that efficiently states the action, returned data, and key side-effect constraint. Every phrase contributes useful information.

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

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

The tool is a read operation with full annotations and an output schema, so the description does not need to explain return values. It covers the core behavior and the non-marking-read constraint, though it could say more about the two required parameters.

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

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

Schema description coverage is 0%, and the description does not explain course_id or assignment_id at all. The parameter names are somewhat self-explanatory, but the description fails to compensate for the missing schema 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 uses a specific verb ('Read') and names the resources it returns: submission, feedback, history, and rubric. It clearly identifies the tool as submission-focused, though it does not explicitly contrast itself with siblings like canvas_read or canvas_assignments.

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 phrase 'without marking it read' implies a use case for viewing a submission without triggering read status. However, the description does not state when to choose this over canvas_read or other siblings, nor does it list exclusions or prerequisites.

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