LMS 할 일 조회

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

Even though annotations already declare readOnlyHint/openWorldHint, the description adds substantial behavioral context: a 1-hour cache (refresh bypasses it), an auto-refresh path that repeatedly calls pull_materials until more is false, then get_assignment for each incomplete assignment, with a short change summary before results. It also states idempotence within a request and warns that LMS text is data, not instructions, which is valuable prompt-injection guidance.

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 purpose, ordering, and scope come first, then follow-up routing, then the auto-refresh protocol, so it is well front-loaded. It is dense and slightly long because the refresh protocol sentence packs multiple steps, but almost every clause conveys actionable behavior.

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?

Since an output schema exists, the description does not need to explain return values, and it covers ordering, scoping, follow-up tools, and refresh side effects well. The remaining gap is that the relationship between the explicit refresh parameter and the implicit pullStale trigger is not clarified, which could confuse an agent deciding whether to pass refresh.

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% (including enum and default descriptions), so the schema carries most parameter meaning. The description adds only for includePast (past-due incomplete items surfaced as overdue at the top) and introduces a 'pullStale' condition that is not an actual parameter, leaving the interaction with the refresh parameter ambiguous.

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

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

The description opens with a specific verb and resource: it retrieves VOD, assignment, and quiz status plus deadlines for Hansung University LMS courses, ordered by deadline urgency. This makes it immediately distinguishable from sibling read tools such as list_courses (course list) and get_assignment (single-assignment detail).

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 clearly states the context (tracked courses follow set_course_tracking, with non-curricular courses excluded by default) and directs follow-up work by noting that each cmid can be passed directly to get_assignment or transcribe_lecture. It does not explicitly state when to prefer a sibling instead (for example, list_courses versus this tool), so it falls short of a full 5.

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