LMS 할 일 캘린더 파일로 내보내기

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

Annotations already declare idempotentHint=true and destructiveHint=false; the description adds real behavioral context beyond them: re-export overwrites the same file, stable per-item UIDs prevent duplicates on re-import, per-app update semantics differ, and completed/deleted items linger in calendars. It also warns that LMS text is data not instructions. Minor gap: no mention of whether the storage directory must be configured first (set_storage_dir exists as a sibling).

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

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

Front-loaded with the action and resulting path, then the import workflow, then caveats in decreasing priority. It is a bit dense with several distinct caveats in one block, but each sentence carries information an agent would otherwise get wrong.

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

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

An output schema exists, and the description still names the returned value (the file path). It covers the non-obvious failure modes (dedup, stale events, skipped items) that no structured field expresses. The only unaddressed prerequisite is the storage-location setup handled by a sibling 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 baseline is 3; the description goes further by declaring the filter semantics equivalent to list_tasks and by explaining that items lacking deadline data are skipped and only counted, which clarifies how withinDays/incompleteOnly actually behave. It does not document the individual enum values or the refresh cache, but the schema does.

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 output artifact: it saves VOD/assignment/quiz deadlines as an .ics file at a named path and returns that path. The selection criteria are anchored to a named sibling (list_tasks), so an agent can distinguish it from the read-only listing tools without opening either schema.

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

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

Makes the use case explicit (import into Google/Apple/Outlook calendars) and ties filtering to list_tasks' criteria, which implicitly routes agents to list_tasks when they only want to view items. It does not state an explicit 'do not use for X' exclusion, but the downstream workflow is clear.

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