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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely valuable behavioral context beyond annotations: the AUTH_REQUIRED/loginUrl failure mode, session-binding requirements, and the default-term fallback when term_id is null. No contradiction exists — the description's read-only framing matches 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?

Single well-organized paragraph with purpose front-loaded first, then prerequisites, options, defaults, sibling routing, and failure recovery in logical order. Each sentence carries distinct information with no repetition of schema content — it is dense but 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?

With no output schema, the description bears responsibility for conveying return behavior, and it covers the key contracts: success content (assignment names/deadlines in compact mode, detailed info otherwise) and the AUTH_REQUIRED error shape with loginUrl. It does not fully enumerate the success response structure, but given the moderate complexity and strong coverage of preconditions and failure modes, the practical essentials for correct invocation are 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 coverage is 100%, so the baseline is 3. The description enriches parameters beyond the schema by tying mcp_session_id to the auth recovery flow, explaining term_id's relationship to get_my_lms_terms, and specifying compact=true's output implications. This cross-parameter workflow context exceeds baseline but the schema already documents each parameter individually, so not 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 (조회/retrieves), resource (미제출 LMS 과제와 퀴즈 — unsubmitted LMS assignments and quizzes), and scope (인증된 학생, authenticated student at SSU Campus). The '미제출' (unsubmitted) qualifier clearly distinguishes it from siblings like get_my_lms_courses, get_my_lms_materials, and get_lms_dashboard.

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 explicit usage conditions: requires mcp_session_id (LMS login), compact=true mode, and term_id defaulting to the LMS default term. It also names the sibling get_my_lms_terms as the prerequisite for cross-term queries and gives a complete AUTH_REQUIRED recovery workflow (show loginUrl, have user log in, retry with issued session). This exceeds 'clear context' and approaches full when/how guidance.

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