Export due dates calendar

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

With annotations declaring readOnlyHint=false, openWorldHint=true, and destructiveHint=false, the description adds substantial context beyond those annotations. It discloses the write-like behavior of saving a file when path is provided, the alternate return of raw calendar text when path is omitted, default exclusion of submitted work, and included event metadata such as course name, points, status, Canvas link, and a day-before reminder.

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 front-loaded with purpose and output modes, then flows into parameters and an example. It is appropriately sized for a tool with five optional parameters and two output paths, though it repeats some defaults already present in the schema, which slightly reduces 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?

There is no output schema, but the description fully explains both return paths: a saved .ics file when path is supplied, or calendar text returned when path is omitted. It also describes event contents and default filtering, leaving no major ambiguity for an agent to call 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?

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds some extra semantic value, notably that course_id can be either a Canvas course ID or a course name, and reinforces the default filtering and lookahead behavior. The remaining parameter details largely restate the schema, so this is a strong 4 rather than a 5.

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

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

The description states a specific verb and artifact: 'Build an iCalendar (.ics) file of Canvas due dates and calendar events.' It also implicitly distinguishes the tool from read-only sibling tools such as get_upcoming_due_dates and get_calendar_events by producing an exportable calendar file that opens in Google Calendar, Apple Calendar, and Outlook.

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 key usage modes: provide a folder in path to save a file, or omit path to receive calendar text. It also gives defaults for filtering submitted work, the 30-day lookahead, and course filtering, with a concrete example. It does not explicitly name alternatives or when not to use this tool, so it falls short of a 5.

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