ssuMCP

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

Annotations already mark this as destructive (destructiveHint=true), and the description aligns by explicitly saying it cancels an active wait. It adds useful context beyond annotations: the precise object being destroyed and the LIBRARY login requirement. No contradiction with annotations is present.

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 with no filler. The main action and scope are front-loaded, and the session requirement is stated in a compact parenthetical.

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 simple one-parameter destructive tool, the description covers what is cancelled, when it applies, and the session/login requirement. However, with no output schema and a destructive operation, it omits the expected result and any required preceding steps such as prepare_cancel_library_seat or confirmation.

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?

The schema fully documents mcp_session_id as optional, with a clear fallback to the current MCP transport session. The description's statement 'mcp_session_id 필요' contradicts this optionality and could mislead an agent into treating the parameter as required. The login context adds some value, but the conflict is harmful.

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, '취소합니다' (cancel), and a clear resource: an active library seat wait intent whose reservation has not started. This distinguishes it from read-only siblings like get_library_wait_status and from wait_for_library_seat, though it does not explicitly name a sibling alternative.

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 gives a clear condition for use ('아직 예약이 시작되지 않은 활성 도서관 좌석 대기 intent') and a prerequisite ('mcp_session_id 필요(LIBRARY 로그인)'). It does not, however, mention alternatives or related workflow steps such as prepare_cancel_library_seat or confirm_action.

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 read-only, idempotent, non-destructive behavior. The description adds useful context that this requires an authenticated SAINT session. It does not disclose return format or edge cases, but the annotation coverage lowers the burden, so a 3 is appropriate.

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?

One concise sentence that front-loads the tool's purpose (query graduation status) and includes the key prerequisite (mcp_session_id / SAINT login). There is no wasted text.

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 simple read-only query with one optional parameter and comprehensive annotations, the description provides enough context for an agent to select and invoke the tool. However, with no output schema, it does not specify the shape of the graduation status result, which is a minor gap.

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 mcp_session_id as optional with a bound-session fallback. The description adds that the session relates to SAINT login but does not add meaningful semantics beyond the schema.

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 ('조회합니다' / queries) and names a specific resource (graduation eligibility and requirement fulfillment in u-SAINT for authenticated students). It is clear about what the tool does, though it does not explicitly differentiate it from the sibling tool evaluate_graduation_with_policy.

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 mentions that a session ID is needed and ties it to SAINT login, but it gives no guidance on when to prefer this tool over alternatives like evaluate_graduation_with_policy or check_scholarship_policy. No exclusions or distinguishing usage scenarios are provided.

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), so the description only needs to add behavioral context. It adds the facts that the comparison is against official grounds and that the returned tierEvaluation is deterministic. However, it does not describe live-fetch versus seed-corpus behavior or the shape of the returned evaluation.

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 sentences, each earning its place: the first states the core comparison behavior, the second clarifies the deterministic output and separation from other decision outputs. The jargon ('tierEvaluation', 'decision/matchedRequirements') costs some clarity, but the text remains compact.

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 read-only policy-check tool with fully described parameters and strong annotations, the description is adequate but not complete. It tells the agent what the tool does and the general output, but leaves out usage conditions, output structure, and live-vs-seed behavior. No output schema exists to fill the gap.

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 description does not need to re-document parameters. It does mention GPA, credits, admission year, and TOPIK, but adds no semantics beyond the schema; live, limit, query, and internationalStudent are only covered in the schema. Baseline 3 is appropriate.

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 concrete verb ('대조합니다') and names the resource (scholarship policy) plus the supported rule families (foreigner/TOPIK/Baekma). It distinguishes itself from 'existing decision/matchedRequirements', but those terms are not sibling tool names and are left undefined, so differentiation is only partial.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The phrase '별도로 지원되는' hints at a separate path from other decision logic, but it does not tell an agent when to prefer this tool over siblings like get_my_scholarships or evaluate_graduation_with_policy.

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 establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by naming the classification categories and the fact that it recommends a follow-up tool, which goes beyond the annotations. The lack of output-format detail is a minor gap.

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 concise sentence that front-loads the action and immediately states the classification categories and downstream recommendation behavior. There is no filler or redundant 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?

For a classification and recommendation tool, the description covers what the tool does and what it returns conceptually: intent labels and a recommended next tool. With no output schema, a bit more detail about the exact response shape would be ideal, but the description is still sufficiently complete for an agent to invoke it 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 coverage is 100%: the single required 'query' parameter already has a description and an example. The tool description adds no further parameter-level detail, but none is necessary because the schema fully documents the parameter.

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 clearly states the tool's action: classify an academic question into four specific intents and recommend the next ssuMCP tool to invoke. This distinguishes it from sibling data-retrieval and action tools, which do actual lookups or mutations rather than routing and classification.

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 makes the usage context clear: it is for academic questions that need intent classification and downstream tool selection. It does not explicitly state when not to use it or name alternative classifiers, but its unique role as a routing/recommendation tool is implied well enough.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, etc.), the description discloses crucial runtime behaviors: re-preparing the same seat/reservation auto-supersedes the pending action, distinct preparations queue independently and cause confirm_action to refuse execution, and the reserve flow is asynchronous while cancel/swap are synchronous. It also states the mcp_session_id/LIBRARY login requirement. These traits are not derivable from the annotations and materially affect how an agent should behave.

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?

Every sentence earns its place: core purpose, single-action default, supersede/multi-action edge cases, how to specify an action, async vs direct sibling flows, and auth requirement. The information is front-loaded with the main verb first and follows a logical order from simple to complex cases. No redundancy or filler, despite the length being justified by the tool's genuinely complex semantics.

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?

Given the high complexity (superseding, multi-action ambiguity, async reservation flow) and the absence of an output schema, the description covers the behavioral contract very well. However, it does not describe what a successful execution returns (acknowledgment, status, error shape) or the edge case of no pending action at all. These are minor gaps for an executing tool, but an output schema or one more sentence on return values would make it complete.

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 adds workflow-level meaning beyond the schema: it explains the multi-pending-action case where action_id must be chosen from a returned list, and it ties action_id to the prepare-response actionId with context on superseding. It also clarifies that mcp_session_id is needed for LIBRARY login while the schema already covers the safe fallback binding. Genuinely useful, though the schema already carried much of the per-parameter meaning.

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+resource: it '최종 확인하고 실행합니다' (finalizes and executes) user-approval pending actions prepared on SSU Campus. It clearly differentiates from siblings by naming the prepare_* tools (which create the pending actions), get_library_wait_status (which checks async results), and cancel_library_wait, so an agent can tell exactly which stage of the workflow this tool occupies.

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 gives explicit when-to-use rules: call without action_id when exactly one action is pending; do not call expecting execution when multiple distinct actions are pending (it returns a list of action_ids instead); pass the prepare response's actionId to target a specific action. It also routes the agent correctly across the workflow, noting that prepare_reserve_library_seat is async and requires get_library_wait_status for final results, while prepare_cancel/swap execute directly. This is unambiguous operational guidance.

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 mark this as non-readOnly and non-destructive, and the description adds meaningful behavior beyond them: asynchronous ZIP build, queued job, 20-minute download link validity, and LMS-login/session requirement. This gives the agent a realistic model of what happens after approval.

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 short, front-loaded, and communicates the core action and outcomes efficiently. However, the final 'mcp_session_id 필요' clause is redundant with and contradictory to the schema, so not every sentence fully 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?

For an async approval action with no output schema, the description covers the key outcomes: queued ZIP build, download capability URL, 20-minute expiration, and auth/session context. It is slightly incomplete because it does not explicitly name prepare_lms_material_export as the prerequisite step and contains the misleading session-required claim.

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, but the description's only parameter-related statement, 'mcp_session_id 필요', directly contradicts the schema's explicit optionality and fallback-to-current-transport behavior. It adds no useful parameter meaning and actively misleads about whether mcp_session_id must be supplied.

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 names a specific verb and resource: approving a pending LMS material export action. It also states the observable outcome (async ZIP build queued, 20-minute capability URL returned), which distinguishes it clearly from generic confirm_action and export_all_lms_materials.

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 establishes clear context: it applies to pending LMS export actions and requires an LMS session. The schema's note about passing the prepare response actionId reinforces the intended prepare-then-confirm flow. It does not explicitly say 'use after prepare_lms_material_export' or contrast itself with confirm_action, so it stops short of full exclusion guidance.

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 indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context: it requires an authenticated student, returns official regulation basis, and safely binds to the current transport session when mcp_session_id is omitted. No contradiction with 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?

Two concise sentences: the first front-loads the core purpose, and the second provides a useful default behavior. There is no filler or redundant expansion.

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 description gives the core purpose and session behavior, but does not differentiate from the closely related sibling check_graduation_requirements. With no output schema, it also leaves the exact return shape somewhat underspecified, though 'status + official basis' gives a basic idea.

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 baseline is 3. The description only restates the mcp_session_id fallback already documented in the schema and adds no new meaning for live or question parameters.

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 action and resource: returning an authenticated student's u-SAINT graduation requirement status together with official policy/regulation basis. It clearly conveys what the tool does, though it does not explicitly distinguish itself from sibling tool check_graduation_requirements.

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?

No guidance is given about when to use this tool versus check_graduation_requirements or other policy-related siblings. The only usage hint is the mcp_session_id fallback behavior, which concerns parameter handling rather than tool selection.

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?

Beyond the sparse annotations, the description discloses that the tool returns a preview rather than a final ZIP, that confirmation is required to issue the download link, that video/audio files are auto-excluded due to capacity limits, and that an LMS session is required. This gives an agent a clear model of side effects and limitations.

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 definition front-loads the most important routing gate, then states the alternative flow, output contents, follow-up action, exclusions, and auth requirement in a compact paragraph. It is dense but not bloated; the only minor redundancy is the session note already covered by the schema.

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 still tells the agent what the preview contains (per-course file list, count, size, excluded items) and what happens next (confirm_lms_material_export → ZIP link). Together with the schema and sibling names, all call-relevant context is 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?

The input schema already documents both parameters at 100% coverage, including term_id fallback and mcp_session_id optional binding, so the baseline applies. The description's note 'mcp_session_id 필요' adds auth context but is slightly less precise than the schema's optional-session behavior and provides no new parameter semantics.

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 identifies a specific action and resource: collecting all courses' LMS materials in one batch and returning an export preview. It also clearly distinguishes itself from single-course material requests by naming the alternative flow.

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 opens with an explicit trigger condition ('only when the user explicitly asks for bulk download of all courses/materials') and an explicit when-not rule for single-course requests, directing agents to get_my_lms_courses → prepare_lms_material_export. It also names confirm_lms_material_export as the next step, so routing is fully specified.

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, and destructiveHint=false, so the safety profile is covered. The description adds the filtering/scoping behavior but does not mention result ordering, pagination, empty-result behavior, or what fields the returned events contain.

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: the first states what the tool returns and how filtering works, and the second gives practical usage examples. There is no repetition, filler, or irrelevant detail.

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 read-only, filtered-list tool, the description covers the key facts: resource, filters, and common use cases, and the schema documents all parameters. The main gap is the lack of explicit differentiation from get_academic_calendar and the absence of any mention of the returned event structure, though neither is strictly required for invoking 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?

All parameters are fully documented in the schema, so the baseline is 3. The description mostly restates 'year, month, keyword' filtering and provides examples already present in the keyword parameter description, adding no new semantic information beyond the schema.

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 clearly states the action ('returns Soongsil University academic calendar events') and the filters ('year, month, keyword'), and it gives concrete use cases like course registration and exams. However, it does not explicitly distinguish this tool from the sibling get_academic_calendar, which appears to target the same resource.

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 provides clear usage context: use it to search academic calendar events filtered by year, month, and keyword, especially for events like registration, class start/end, and exams. It does not, however, name alternatives or state when not to use it, leaving the comparison with sibling tools implicit.

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 establish readOnly and idempotent behavior. The description adds meaningful detail beyond them: the exact return record shape, ISO date formats, the inclusive endDate semantics for multi-day events, and the null endDate for single-day events. This is strong behavioral disclosure, though it does not cover edge cases like empty results.

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 sentences with no filler: purpose first, then return format, then date conventions and default behavior. Each sentence earns its place and the structure is front-loaded.

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 tool with one optional parameter, the description is complete: it explains what is returned, the shape of each record, the meaning of fields, and default year behavior. No output schema exists, but the description compensates fully.

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%: the schema already documents the year parameter and its default. The description only repeats that default and adds no additional parameter semantics, so the baseline 3 applies.

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 clearly states a specific verb ('조회합니다' / retrieve) and resource ('숭실대학교 학사일정') and enumerates event types such as course registration, midterm/final exams, and vacations. However, it does not explicitly distinguish itself from the similarly named sibling find_academic_calendar_events, so it misses the differentiation needed for 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?

The description gives clear context for using the tool—academic calendar queries—and explains the optional year parameter. It provides no guidance on when to choose this tool over find_academic_calendar_events or any other sibling, leaving the when-not-to-use/alternatives dimension implicit.

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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral detail: it separates answer/facts from citations, reports unconfirmed matters, and includes revision verification status. This reveals output structure and caveats that annotations do not express. No contradiction exists.

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, dense sentence that front-loads the purpose and then specifies the key output components. Every clause adds information: evidence basis, answer/facts separation, unconfirmed items, and revision verification status. No redundancy or filler.

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?

Given the lack of an output schema, the description does a good job of summarizing the return composition, but it remains high-level. It omits details about how the brief is structured, what filters like 'live' affect in terms of output confidence, and how this relates to sibling policy tools. Still, the core behavior is sufficiently conveyed for an agent to select and invoke the 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific guidance beyond echoing the 'query' concept ('학사 질문'). It does not explain nuance around 'live', 'limit', or 'category', but the schema fully covers those parameters.

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 and resource: it returns an evidence-based academic policy brief with answer/facts and citations, including unconfirmed items and revision verification status. This clearly goes beyond the tool name. However, it does not explicitly differentiate itself from sibling search_academic_policy_sources or list_academic_policy_sources beyond implying synthesis.

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 '학사 질문에 대해' implies the tool is for academic policy questions that need evidence-backed answers. Yet there is no explicit when-to-use vs alternatives guidance, such as when to choose this over check_graduation_requirements, evaluate_graduation_with_policy, or search_academic_policy_sources. Usage context is inferable but not stated.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the active/deadline filter, but it does not mention ordering, pagination, or whether the result includes all notice fields.

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 two short sentences with no redundant wording. The core behavior is front-loaded, and the practical use case adds value without bloating the text.

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 simple read-only list tool with one optional parameter, the description covers the core behavior and intended use. The absence of an output schema makes return details unspecified, but the tool's simplicity and annotations make this acceptable.

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 optional category parameter is already documented in the schema. The description adds no new parameter-level guidance, but the schema is sufficient; hence the baseline score is appropriate.

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 clearly states a specific verb and resource: it returns only ongoing notices (before deadline). This distinguishes it from siblings like get_recent_notices, which return notices without the active-status restriction. The use case of checking imminent-deadline or currently applicable notices further clarifies its purpose.

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 gives a clear context for use: when you need active, not-yet-closed notices. It implies the distinction from broader notice-retrieval tools, though it does not explicitly name alternatives or state when not to use it.

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?

Beyond the readOnlyHint/idempotentHint annotations, the description adds valuable behavioral details: the exact status enum, the distinction between missing and invalid session IDs, and the fact that sessions persist across server restarts via the database. No contradictions with annotations exist.

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 compact but information-dense: it front-loads the purpose, then systematically explains all status values, practical usage guidance, and persistence behavior. Every sentence contributes meaning without redundancy.

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 compensates by explaining the status field and the linked field for providers. It also covers the key operational context—when to call it, what each status means, and how to recover from an invalid session—making it sufficient for correct invocation.

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?

The schema already documents mcp_session_id and covers 100% of parameters, so the baseline is 3. The description adds meaning by tying the absence or invalidity of the parameter directly to the NO_SESSION and INVALID_SESSION statuses, which goes beyond the schema text.

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 clearly states it returns the current authentication session status for SSU Campus, which is a specific verb and resource. It also distinguishes itself from sibling auth tools like start_auth and logout_all by enumerating the exact status values and their meanings.

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 explicitly tells the agent to call this tool before invoking other authentication tools to reduce unnecessary AUTH_REQUIRED retries. It also directs the agent to start_auth when INVALID_SESSION occurs and warns not to treat that state as a login failure.

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 with readOnlyHint, idempotentHint, and destructiveHint. The description adds the useful scoping behavior that only department-specific notices are returned, but it does not disclose output format, ordering, pagination behavior beyond the page parameter, or behavior for unknown department names. No contradiction.

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?

One concise sentence with concrete examples, no filler, and the core scoping information front-loaded. It earns its place by showing realistic department values.

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 simple two-parameter, read-only, idempotent tool with full schema coverage, the description is sufficiently complete. It states the filter and provides input examples, though it could be stronger by mentioning alternatives or exact-match expectations.

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%, with both page and department already having meaningful descriptions. The examples in the description largely duplicate the schema examples, adding only slight reinforcement of what values department can take.

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 clearly states the tool returns notices for a specific department/division, using a specific verb and resource, and gives concrete examples. It does not explicitly distinguish itself from siblings like search_notices or get_recent_notices, so it stops short of 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?

The phrase '특정 학과/부서 공지만 반환합니다' implies this tool is for department-scoped notice retrieval, and the examples clarify valid inputs. However, it gives no explicit guidance on when to prefer this over alternatives such as search_notices, get_active_notices, or get_notice_detail.

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 the read-only/idempotent/non-destructive safety profile, so the description adds value by disclosing the result scope: seven days of breakfast/lunch/dinner plus closure information. No contradiction with 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?

A single, front-loaded sentence states the resource, scope, and return contents with no filler. Every clause contributes 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?

For a parameterless read-only lookup with no output schema, the description is complete: it names the exact cafeteria, the week period, the meal types, and the closed-day information. An agent has enough context to invoke it 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?

The tool has zero parameters and the schema is empty, so there are no parameter semantics for the description to clarify. Under the rubric, zero parameters earns a baseline of 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 specific verb ('조회합니다') and a specific resource: Soongsil University Residence Hall cafeteria's weekly menu. It also specifies the time scope ('이번 주'), which helps distinguish it from generic meal tools, though it does not explicitly name sibling alternatives like get_meal_by_date or get_today_meal.

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 gives clear context for when the tool is appropriate: retrieving the dormitory cafeteria's current-week menu, including seven days of meals and closure info. It does not provide explicit when-not-to-use guidance or name alternatives, so it stops 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.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral detail beyond those: it returns away-status seats, explains compact/truncated/hasMore semantics, notes real-time nature, and clarifies that externalSeatId is consumed by a related reservation tool. No contradictions with 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 efficient and front-loaded: it opens with the core purpose, then lists return contents, parameter behaviors, metadata flags, the alternative sibling tool, and authentication requirement. Each sentence carries distinct useful information with no filler.

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 present, the description fully compensates by specifying return fields (available count, externalSeatId, seat numbers, away seats, truncated/hasMore), auth requirements, pagination, and how the result connects to reservation workflows. An agent has enough context to call this tool and interpret its response.

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?

Although schema coverage is 100%, the description meaningfully extends parameter understanding: it defines limit's maximum as 200, specifies that limit/offset apply per-room arrays, explains that compact=true omits seat ID/number arrays, and describes mcp_session_id fallback behavior. This goes well beyond the schema descriptions.

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 resource: it querys real-time reservable seats across all 7 library rooms at Soongsil University, returning per-room available counts, externalSeatId lists, and seat numbers. It also explicitly distinguishes itself from get_room_available_seats by framing this as the whole-library overview tool, so an agent can tell them apart.

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 gives clear usage context: use this for overall library seat availability, then follow up with get_room_available_seats for detailed views of a specific room. It also mentions that externalSeatId feeds into prepare_reserve_library_seat and that mcp_session_id requires LIBRARY login, giving both workflow and prerequisite guidance.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds meaningful context beyond this: the catalog is a static snapshot (not real-time), the data source is screenshots, and no authentication is required — information that shapes an agent's expectations about freshness and invocation prerequisites. This exceeds the minimal safety-only coverage.

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 four-sentence Korean description is tightly written and front-loaded: the first sentence states the core purpose, the second sets exclusions, and the third gives parameter guidance. The only waste is '인증 불필요' (no auth required) repeated at the end after '인증도 필요하지 않습니다' in sentence two — a minor redundancy that prevents a perfect score.

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 simple read-only catalog tool with zero required parameters, fully documented schema, and comprehensive annotations, the description is nearly complete. It covers what the tool returns, what it excludes, authentication requirements, and one parameter's usage scenario. The only minor gap is that the default return format is not precisely described — 'built from screenshots' implies image or structured layout data, but the exact representation is left to inference.

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 three parameters (room_code, floor_code, include_layout) with examples like 'open-reading-2f'. The description adds modest value by hinting at the purpose of include_layout for text-based floor layouts, but it adds nothing beyond the schema for room_code or floor_code. This matches the baseline-3 expectation for fully-covered schemas.

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 resource: it returns a static catalog of Soongsil University library reading room/seat layout maps built from screenshots. It explicitly distinguishes itself from real-time sibling tools by stating '실시간 좌석 현황은 포함하지 않으며' (does not include real-time seat status), which separates it from get_library_seat_status, get_library_available_seats, and get_room_available_seats.

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 gives clear context on when this tool is appropriate: when a static layout catalog is needed rather than real-time seat data, and notes that no authentication is required. It also instructs when to use the include_layout parameter ('LLM이 간단한 텍스트 기반 층별 배치도가 필요할 때'). However, it never names a specific alternative tool to use when real-time status IS needed, stopping short of the explicit routing the top tier demands.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds meaningful behavioral context: the seat aggregation is public, authentication is not required, the tool is read-only, and reservation is out of scope. It also describes the response contents, which helps an agent understand what to expect. No contradiction with 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 well structured: purpose first, then response contents, then compact behavior, then auth and reservation notes. It is concise, though the read-only note and compact=true support partly repeat what annotations and schema already provide.

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 simple read-only status lookup with no output schema, the description provides enough: it explains what the response includes, states that no authentication is required, and clarifies scope. Combined with the 100% schema coverage, an agent can select and invoke the tool correctly without missing critical information.

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%, and the schema already documents the floor values and the compact parameter behavior. The description only repeats that compact=true is supported without adding meaning beyond the schema, so the baseline score applies.

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 clearly identifies the operation: retrieving current library seat status by floor, and specifies the response contents (total/available/reserved/unavailable counts and area distribution). It is clear and specific, but it does not explicitly differentiate from sibling tools such as get_library_available_seats or recommend_library_seats.

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 gives useful usage context: the data is public, no authentication is needed, the tool is read-only, and seat reservation is intentionally kept in separate action tools. It does not name the specific alternative tools, but it does provide an explicit exclusion for reservation-related tasks.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds complementary context: default behavior (most recent intent), the possibility of concurrent intents from confirm_action, and the authentication requirement (LIBRARY login). The 'mcp_session_id 필요' phrasing is slightly ambiguous against the schema's optional marking, but in context it reads as 'a session with LIBRARY login is required' rather than 'this parameter is mandatory.'

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 sentences with zero redundancy: purpose first, then the default behavior, then the exception case and auth note. Every sentence earns its place and the most decision-relevant information (when to omit vs. specify intent_id) is front-loaded.

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?

Invocation semantics are fully covered: default behavior, the multi-intent exception, and the authentication requirement. With no output schema, the description does not describe the response shape or possible status values, which is a minor gap for an agent deciding next steps in the wait flow, but the calling logic itself is complete.

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 schema already documents both parameters and their defaults, placing this at baseline 3. The description adds scenario context for intent_id (the confirm_action multi-intent case) beyond the schema's explanation, plus the LIBRARY login requirement for the session. These additions are useful but marginal rather than compensating for any schema 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?

The description states a specific verb and resource: '도서관 좌석 대기/예약 intent 상태를 조회합니다' (queries library seat waiting/reservation intent status). The resource is precise — the intent state, not the seat itself — which implicitly separates it from siblings like get_library_seat_status and get_my_library_seat. However, it never names a sibling explicitly, so differentiation is implicit rather than stated.

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 gives explicit parameter-selection guidance: omit intent_id when only one wait intent exists (the common case), and pass the intentId from a confirm_action response when multiple intents may be in flight. It clearly marks the multi-intent case as the exception that requires the explicit ID. It does not, however, address tool-level alternatives or conditions for not using this tool at all.

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, and destructiveHint=false, covering the safety profile. The description adds important behavioral context beyond annotations: authentication is required, and term selection defaults to the current term when term_id is omitted.

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 two compact sentences with no filler. The main dashboard function and data categories are front-loaded, followed by the optional-term behavior and the authentication prerequisite.

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 still conveys what the tool returns: a summary of deadlines, academic calendar items, and active notices. It also covers auth and the optional term parameter. It is complete enough for an aggregate read-only dashboard tool, though it does not mention error cases or response format details.

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 both term_id and mcp_session_id are already documented. The description adds the requirement to pass mcp_session_id after LMS authentication and reinforces term_id omission behavior, but this largely overlaps with the schema and provides no new parameter-level meaning.

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 clearly states the tool summarizes an authenticated user's LMS dashboard: unsubmitted assignments/quiz deadlines, academic calendar items, and active notices. It is distinguishable from sibling tools like get_my_assignments or get_academic_calendar because it explicitly says it aggregates 'at once,' but it does not explicitly name or contrast those siblings.

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 gives clear context: it is for authenticated users, requires start_auth via LMS provider, and automatically selects the current term if term_id is omitted. It does not explicitly state when not to use it or which alternative to choose for detailed data, so it stops 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.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: an empty restaurant argument returns menus for all restaurants along with closed-day information, while a specified restaurant limits the query. This clarifies the tool's aggregation behavior without contradicting any annotation.

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 compact at three sentences, front-loads the core purpose and date format, and each sentence contributes distinct information: what is queried, what happens when restaurant is empty, and what happens when restaurant is specified. There is no redundant or filler content.

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 simple read-only tool with two parameters and no output schema, the description covers the essential request semantics and response scope, including all-restaurant versus single-restaurant behavior. It could be slightly more complete by describing the return structure or what happens when no menu exists for the date, but the schema and annotations cover the remaining critical details.

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?

The input schema already covers both parameters with 100% coverage, so the baseline is 3. The description adds extra value by explaining the effect of leaving restaurant empty versus providing a value, which reinforces the schema's guidance and clarifies the scope of the result set.

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 clearly states the tool's action: querying the Soongsil University student cafeteria menu for a specified date in yyyy-MM-dd format. It also distinguishes behavior based on whether the restaurant parameter is provided, which separates it from date-specific meal tools like get_today_meal or get_meal_weekly.

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 gives concrete guidance on how to use the restaurant parameter: leave it empty for all campus restaurants or specify one for a single restaurant. However, it does not explicitly contrast this tool with sibling tools like get_today_meal, get_meal_weekly, or get_dorm_weekly_meal, so the when-to-use-vs-alternatives guidance is only implied rather than stated.

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 the operation read-only and idempotent. The description adds behavioral detail beyond that: the result is 7 days starting Monday, and the default offset behavior. It does not discuss response format or error conditions, but for a simple read-only query this is a reasonable level of disclosure.

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 compact sentences with no filler: purpose first, then parameter behavior, then sibling routing. Every sentence contributes unique 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?

For a single-optional-parameter read-only tool, this is complete: it covers what is returned, the default, the offset semantics, and the correct sibling for dormitory menus. The output shape is not described, but the term 'menu' and the read-only annotations make the expected result clear.

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 adds value by stating the default (0), that 0 means the current week from Monday, and that 1 means next week. It omits repeating the -1 case, but the schema already documents it.

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 action ('조회합니다') and resource ('숭실대학교 학생식당의 주간 7일 메뉴'), and clarifies it is for the student cafeteria rather than the dormitory. It also differentiates from the sibling get_dorm_weekly_meal by explicitly naming that alternative.

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 explains when to use each offset value (weekOffset=0 for this week from Monday, weekOffset=1 for next week) and explicitly says to use get_dorm_weekly_meal for dormitory weekly menus. This gives the agent clear selection criteria rather than leaving the choice implicit.

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 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.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate those. It adds useful behavioral context about default semester selection and SAINT session requirements, which goes beyond the structured 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?

Two concise, front-loaded sentences: the first states the tool's purpose, the second covers parameter defaults and authentication requirements. Every clause adds value and there is no filler.

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 simple read-only getter with three fully documented optional parameters, the description is largely complete: it covers scope, defaults, and auth. It does not describe the exact return shape, but with no output schema and a familiar attendance-info resource, this is a minor gap.

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 adds meaningful extra semantics by explaining that omitted year/semester fall back to the current u-SAINT term and that a SAINT login session is required. The phrase 'mcp_session_id 필요' is slightly ambiguous against the schema's optional flag, but it likely refers to needing an active session rather than mandating the parameter.

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), a precise resource ('u-SAINT 채플 출석 정보'), and a clear scope ('인증된 학생'). This is distinctive enough to separate it from sibling tools like get_my_schedule or get_my_grades without requiring schema inspection.

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 gives practical usage context: year and semester are optional and default to the current u-SAINT semester, and an mcp_session_id / SAINT login is needed. It does not explicitly name alternatives, but the context is clear and there are no confusing exclusions.

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?

Goes beyond annotations by disclosing the unauthenticated behavior (returns AUTH_REQUIRED with loginUrl) and instructing the agent to guide the user through login and re-invoke. Annotations already cover read-only and idempotent hints, and the description complements them without contradiction.

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 concise, purposeful sentences. The primary function is front-loaded, followed by the session requirement and authentication failure handling. Every sentence earns its place with no redundancy.

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 adequately conveys the return content (cumulative grades and semester GPA history) and the main failure mode (AUTH_REQUIRED with loginUrl). It stops short of describing the exact result structure, but it is sufficient for correct invocation and basic error recovery.

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?

Input schema coverage is 100%, and the mcp_session_id parameter is already well-described in the schema with its fallback behavior. The description reinforces the parameter's necessity and auth flow but adds no new semantic meaning beyond the schema baseline.

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 clearly states the specific action ('조회합니다' / retrieves) and resource ('u-SAINT 누적 성적' / cumulative grades with semester GPA history). It distinguishes itself from siblings like get_my_scholarships and simulate_gpa by focusing on actual stored grades plus GPA history.

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 usage context: requires mcp_session_id and explains the exact re-auth workflow with AUTH_REQUIRED and loginUrl. It does not explicitly mention alternatives or when not to use the tool, so it falls slightly 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the tool is auth-gated, and unauthenticated calls return AUTH_REQUIRED carrying a loginUrl, with a prescribed re-invocation flow. No contradiction with 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?

Two sentences with no wasted words: the first front-loads the core purpose and output content, the second covers the prerequisite and the auth-failure recovery path. Every clause 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?

The tool is simple (one optional parameter, no output schema) and the description covers purpose, return content (loans with due dates), the auth prerequisite, and the failure mode. A bit more detail on the returned loan fields would help, but nothing needed for correct invocation is missing.

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%, giving the parameter its own baseline of 3. The description adds meaning beyond the schema by clarifying that mcp_session_id must be tied to LIBRARY authentication and explains the consequence of an invalid/missing session (AUTH_REQUIRED), which is behaviorally important for correct invocation.

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), a specific resource (the authenticated user's current library loans), and a concrete output detail (with due dates). This clearly differentiates it from sibling library tools like get_my_library_seat, get_library_wait_status, and search_library_book, which concern seats, waitlists, and book search rather than loans.

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 gives explicit usage context: an mcp_session_id authenticated against LIBRARY is required, and it spells out the full failure-recovery flow — when AUTH_REQUIRED with loginUrl is returned, show loginUrl to the user, guide browser login, and re-call with the issued session. It does not explicitly name alternatives, but the loan-specific purpose already distinguishes it from siblings.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: it will explicitly report when there is no reserved seat, and it requires a LIBRARY-authenticated session.

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 sentences front-load the core purpose, then add the empty-result behavior, alternatives, and session requirement. No filler; each 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?

For a read-only, single-optional-parameter lookup, the description covers what the tool does, the no-result case, the session prerequisite, and relevant action alternatives. It does not enumerate returned fields, and there is no output schema, but the level of detail is sufficient for correct selection and invocation.

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?

The input schema already documents mcp_session_id as optional with a bound-session fallback (100% coverage), so the baseline is 3. The description adds the LIBRARY-login auth requirement, which clarifies what kind of session is needed beyond the schema text. The wording '필요' is slightly looser than the schema's optional flag, but the intended meaning is clear.

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) and a specific resource: the currently reserved library seat. It also covers the empty-result behavior ('no reserved seat -> says none') and explicitly names the sibling tools for canceling and swapping, so an agent can distinguish the query action from follow-up mutations.

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 tells the agent exactly when to use this tool: to check the current reserved seat, and explicitly routes to prepare_cancel_library_seat for returning and prepare_swap_library_seat for changing seats. It also states the LIBRARY-login session prerequisite, which is key context for selecting this tool successfully.

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 non-destructive, so safety is covered. The description adds concrete behavior beyond annotations: it returns aggregated per-course stats (file count, total size, extension groups), includes content_id per file, auto-selects the active term when term_id is omitted, and requires/uses mcp_session_id for LMS login context. It also exposes an implicit behavior of presenting a summary table to the user. Minor gap: no mention of what happens if the user has no enrolled courses or no files, but the description does considerably more than the annotations require.

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 information-dense and front-loaded with the core purpose and value proposition, then flows into usage and follow-up instructions. It is longer than minimal, but every sentence earns its place by explaining the aggregated content, the user interaction step, and the follow-up call. A minor deduction for density: multiple clauses per sentence may require re-reading, but the structure is logical and not padded.

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 read-only list tool with 2 optional parameters and no output schema, the description is remarkably complete: it states what is returned (file count, total size, extension groups, content_id), how to surface it to the user, which sibling to use next and why get_my_lms_materials is unnecessary, and the default term selection behavior. There is no output schema, so the description must specify return contents—and it does. The only minor omission is empty-state behavior, but this does not meaningfully hurt callability.

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 schema already documents both parameters (term_id and mcp_session_id) with meaningful descriptions. The tool description adds context for term_id's default behavior and states mcp_session_id is needed for LMS login, but doesn't add new parameter syntax or format details. Baseline 3 is appropriate because the schema carries the burden and the description only slightly supplements it.

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+resource (retrieves the authenticated user's LMS courses) and specifies a key differentiator: it bundles downloadable materials per course. It clearly distinguishes from sibling get_my_lms_materials by explaining that this one returns content_id per file and removes the need for a second call.

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 says to call this right after login, describes the user-facing table format, instructs how to ask the user which course to receive, and directs the follow-up call to prepare_lms_material_export using the content_ids from this response. Also explains term_id behavior when omitted and notes that mcp_session_id is required (LMS login). This is strong usage guidance with invocation ordering and next-step routing.

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 mark the tool as read-only, idempotent, and non-destructive, so the description adds useful behavioral context: results are grouped by file extension, video/audio are excluded for security/capacity reasons, and the current active term is auto-selected when term_id is omitted. Without an output schema, this return-structure summary is valuable.

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 concise and front-loaded: purpose first, then result grouping, exclusions, term default, and authentication requirement. Every sentence adds necessary information and there is no filler.

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 read-only lookup with no output schema, the description covers the resource, scope, exclusions, result grouping, term fallback, and auth prerequisite. It could be slightly more explicit about empty-result behavior or limits on the number of courses, but it is largely sufficient.

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 baseline is 3. The description adds useful meaning: course_ids come from get_my_lms_courses, and term_id defaults to the active term. However, it states 'mcp_session_id 필요' (mcp_session_id required) while the schema marks it optional with a fallback, creating a contradictory usage signal.

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 (조회/retrieve) and an exact resource: weekly learning materials for specified LMS courses, listing common file types and explicitly excluding video/audio. This also distinguishes it from sibling export tools like export_all_lms_materials and prepare_lms_material_export, since this is a read-only list operation.

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 provides clear context: it takes course_ids, defaults to the active term when term_id is omitted, and requires an LMS session. It does not explicitly name alternatives or state when not to use this tool, but the read-only list purpose and explicit exclusion of video/audio imply 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 provide readOnlyHint, idempotentHint, and non-destructive guarantees. The description adds meaningful behavioral context: LMS login is needed via mcp_session_id, only one active term has defaultTerm=true, and the default term is used when term_id is omitted. This goes beyond what annotations convey.

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 compact and front-loaded: purpose first, then output contents, then key defaultTerm behavior, then downstream usage, then authentication note. Every sentence earns its place and there is no filler.

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 simple, read-only, zero-required-parameter tool, the description covers return fields, default-term semantics, downstream usage, and authentication needs. It loses one point because it references get_my_lecture_list, which is not present in the sibling list, and because exact date formats or error behavior are not mentioned — though the latter is minor.

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% and the only parameter, mcp_session_id, is already well-described in the schema as optional with transport-bound session fallback. The description adds the LMS login requirement, which is mildly useful, but it does not substantially extend the schema's parameter 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 clearly states the tool returns the user's LMS registered term list, with concrete fields (id, name, start/end dates, defaultTerm). It is distinguishable from related get_* tools because it focuses specifically on terms rather than courses, schedules, or dashboard data.

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 gives clear context: it should be used to obtain term IDs, especially the default active term, and those IDs feed into get_my_assignments (and get_my_lecture_list). It does not explicitly state when NOT to use it versus siblings, but the downstream usage guidance is strong enough.

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?

Beyond the readOnly/idempotent/destructive annotations, the description discloses the authentication prerequisite, the AUTH_REQUIRED response with loginUrl, and the expected retry flow. No contradiction with 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?

Four sentences, all load-bearing: what it returns, default vs specific semester behavior, term codes, and auth retry instructions. No filler and the core purpose is front-loaded.

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 simple read tool with no output schema, this is complete: all parameters are covered, default behavior is specified, and the only notable edge condition (unauthenticated) is handled explicitly with a remediation path.

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 adds meaning by explaining the term code mapping, the default current-semester behavior when year/term are absent, and the role of mcp_session_id in the login flow, which goes beyond the schema descriptions.

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 names a specific resource (u-SAINT timetable of an authenticated student at SSU Campus) and a specific action (retrieve grouped by subject). This is distinguishable from sibling tools like get_my_grades or 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?

It gives clear usage context: omit year/term for the current u-SAINT semester, pass both for a specific one, and describes the auth failure flow. It does not explicitly name sibling alternatives or state when not to use it, so not 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 behavior. The description adds useful context about authentication via SAINT login and the optional year behavior. However, it introduces some ambiguity by saying 'mcp_session_id 필요' while the schema marks it optional, which slightly weakens transparency.

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 concise sentences, front-loaded with the main purpose and immediately followed by parameter behavior. No filler or redundant restatement of the tool name.

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 simple read-only lookup with zero required parameters and a 100% schema-covered input schema, the description covers the essential context: who is eligible, what data is returned, and how optionality works. It does not specify response shape, but the absence of an output schema makes this a minor gap.

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 adds meaningful behavior beyond the schema: omitting year returns the full available history, and mcp_session_id is tied to SAINT login. This extra semantic context helps an agent choose and fill parameters correctly.

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?

Description states a specific verb (조회합니다/retrieve) and a specific resource (authenticated student's u-SAINT scholarship benefit history), clearly distinguishing it from sibling tools like check_scholarship_policy or get_my_grades.

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?

Clearly states the tool is for authenticated students and explains the optional year parameter behavior (omitting it returns all available records). It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for the main use case.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the tool returns the full body text and expects an unmodified link value, which is useful but not a rich behavioral disclosure beyond what annotations already imply.

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, with the purpose stated first and the parameter source instruction second. There is no wasted text, and the structure is easy for an agent to parse quickly.

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 simple read-only tool with one fully documented parameter and no output schema, the description is complete. It identifies what the tool returns, how to obtain the input, and the fact that the input should be passed unchanged.

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 the url parameter and its source as the link value from get_recent_notices/search_notices. The description adds only a slight nuance by saying 'pass it as-is' (그대로), which is minor additional guidance.

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 clearly states the tool returns the full body text of a notice given its URL, using a specific verb and resource. This distinguishes it from siblings like get_recent_notices and search_notices, which list notices rather than fetch detail content.

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 provides clear usage context by instructing the agent to pass the link value from get_recent_notices or search_notices results. It implies this tool should be used after those listing tools when full notice content is needed, though it does not explicitly discuss when not to use it.

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, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about category filtering and compact-mode support, but stops short of describing pagination behavior, result limits, or what fields come back — and 'compact=true 지원' is a bare feature flag that the schema has to explain.

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 Korean sentences with the core purpose front-loaded; no filler or repetition. The compact mention is terse enough to seem cryptic without the schema, which keeps this from a 5.

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 simple read-only list tool with rich annotations and fully documented parameters, the description is mostly adequate. Gaps: there is no output schema to define the return format and the description does not cover it, nor does it clarify page/pagination semantics or differentiate from get_active_notices/search_notices.

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 baseline is 3; the schema already documents page defaults, compact's return differences, and the full category list. The description adds modest value by stating category's filtering role and pointing to list_notice_categories, but nothing beyond that.

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+resource: '공지사항 최신 목록을 조회합니다' (retrieves the latest notice list), and adds the category-filtering scope. However, it never distinguishes itself from closely related siblings like get_active_notices, get_department_notices, or search_notices, so an agent must infer which notice-listing tool fits the task.

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 provides one useful routing pointer — use list_notice_categories to obtain valid category values — but gives no when-to-use versus when-not-to-use guidance relative to the four other notice tools. Usage context is implied ('최신' = latest) rather than stated as a selection rule.

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?

Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description discloses real-time behavior, possible seat statuses, the LIBRARY session/login requirement, pagination via compact/offset/limit, and the downstream use of externalSeatId. The only minor ambiguity is that 'mcp_session_id 필요' could be read as requiring the parameter, while the schema marks it optional; this is better interpreted as requiring a valid session.

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 return shape, then moves through room IDs, pagination, and authentication. Each sentence carries operational value, and the dense information is still scannable and well organized.

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 there is no output schema, the description correctly supplies the key return fields and status values an agent needs to interpret results. Combined with full parameter documentation in the schema and safety-related annotations, the description is complete enough for an agent to invoke this tool correctly and understand what it returns.

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 baseline is 3. The description adds floor-level context for roomId values (e.g., 15 = 1열람실 B1F), clarifies the 200-item limit, and explains how externalSeatId relates to reservation preparation. This goes beyond the schema without replacing it.

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 resource: it performs a real-time query of all seat statuses for a specific library reading room and enumerates the returned fields (status, label, seat type, remainingTime). It also gives concrete roomId values, which distinguishes it from broader sibling tools like get_library_available_seats or get_library_seat_status.

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 implies when to use the tool: when an agent needs per-seat status for a specific reading room, and it further explains that externalSeatId should be passed to prepare_reserve_library_seat. However, it does not explicitly contrast this tool with siblings such as get_library_seat_status or get_library_available_seats, nor state when not to use it.

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 non-destructive behavior, so the bar for extra disclosure is lower. The description adds useful behavioral context: the all-restaurant mode returns per-corner menus and closed-day information, and the specific-restaurant mode returns only that restaurant. There is no contradiction with 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 compact and front-loaded, with two sentences and no filler. The only minor flaw is a slight ambiguity: the first sentence says 'student cafeteria menu,' then immediately broadens the default behavior to all campus restaurants, which could confuse an agent on first read.

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 simple read-only tool with one optional parameter, the description covers the essential behavior, default scope, and included closed-day information. It does not specify whether the single-restaurant result also includes closed-day info or how an invalid restaurant name is handled, but these are small gaps for such a lightweight 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?

The input schema already documents the optional restaurant parameter at 100% coverage, including allowed values and the empty-vs-specified behavior, so the baseline is 3. The tool description repeats much of this and adds only a small increment: that the all-restaurant result includes corner menus and holiday/closed-day info.

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 clear verb and resource: it retrieves today's meal menus for Soongsil University cafeterias, and it explains the two scope modes (all restaurants vs. one named restaurant). It does not explicitly differentiate itself from meal-related siblings such as get_meal_by_date or get_meal_weekly, so it falls just short of full sibling differentiation.

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 gives practical guidance on the restaurant parameter: leaving it empty returns all campus restaurants, and specifying it narrows the result to one restaurant. However, it never tells the agent when to choose this tool over the alternative meal tools in the sibling list, so the when-not-to-use guidance is missing.

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 the read-only, idempotent, open-world, non-destructive profile. The description adds useful behavioral context beyond those annotations by specifying what kind of data is returned and by indicating through the live parameter that a live corpus loading path is used when live=true. No annotation contradiction exists.

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 two short sentences with no filler. It front-loads the primary purpose and then lists the concrete output fields, keeping the definition compact and scannable.

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 description names the output fields explicitly, which is important because there is no output schema. It is complete enough for a read-only metadata-listing tool with fully documented optional parameters, though it could have noted why one would inspect the source list before using related policy tools.

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 both parameters are already documented. The description adds no further parameter-level semantics; it only mentions 'live 지원 여부' as an output field, not as an input behavior. Baseline 3 is appropriate.

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 action and resource: returning the list of official sources queried by the academic RAG, and enumerates the inspectable fields (URL, contentUrl, revision/effectiveDate, live support, verification date). This clearly distinguishes it from the sibling search_academic_policy_sources, which is about searching/policy content rather than listing source metadata.

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 gives no explicit guidance on when to use this tool versus alternatives such as search_academic_policy_sources or get_academic_policy_brief. The only usage-related hint is within the parameter description ('list only' recommends false/omitting live), which concerns parameter selection, not tool selection.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the returned values are meant for the category parameter of two sibling tools, which is useful but not a deep behavioral disclosure beyond the annotations and purpose.

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 two short sentences with no filler. The first sentence states the core function and the second explains the practical use case, earning 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?

For a read-only, zero-parameter list operation with strong annotations, the description is complete: it says what is returned and why an agent would need it. No output schema is present, but a simple category list does not require a detailed return-shape explanation.

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?

The tool has zero parameters and the input schema is fully covered, so there is no parameter information for the description to add. This matches the baseline for a zero-parameter tool.

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 resource: it 'returns the list of notice categories' for Soongsil University notices. It also identifies the downstream consumers (get_recent_notices, search_notices), which distinguishes this tool from sibling notice tools that return notices rather than category lists.

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 explicitly says the tool is useful for checking values usable in the category parameter of get_recent_notices and search_notices, giving clear context for when to call it. It does not explicitly state when not to use it, but there are no obviously competing category-listing siblings, so the guidance is sufficient.

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 flag destructiveHint=true and readOnlyHint=false, and the description complements this by naming exactly what gets destroyed: all connected providers and the whole session. It also discloses the safe fallback to the current transport-bound session when mcp_session_id is omitted, adding context 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 states the main destructive action first, then the only optional parameter behavior. Every element earns its place with no filler.

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 one-optional-parameter destructive action with no output schema, the description covers the core action, scope, and fallback. It does not elaborate on post-logout state or irreversibility, but the destructiveHint annotation plus the explicit 'remove all' scope make the behavior reasonably complete.

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 baseline applies. The description restates the optional mcp_session_id fallback already documented in the schema, adding no new semantic information beyond what the input schema provides.

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 ('removes') and a precise resource: all providers connected to the entire SSU Campus MCP authentication session. The scope word 'all' differentiates it from the sibling logout_provider without requiring additional inference.

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 implies a broad logout-all use case ('all providers', 'entire session'), but it never explicitly states when to prefer this over logout_provider or when not to use it. The fallback behavior for mcp_session_id is explained, but that is parameter guidance rather than alternative selection guidance.

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?

The annotations already declare destructiveHint=true, and the description adds useful scope: the operation removes a specific provider's connection from the MCP session, not the entire session or all providers. It also clarifies that omitting mcp_session_id safely binds to the current transport, which is meaningful behavioral context 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 two short sentences with no filler: it front-loads the main action and target, then states the required parameter and the optional session behavior. 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?

For a simple two-parameter destructive logout operation with full schema coverage and destructive annotations, the description provides sufficient context: target, scope, required parameter, and session fallback. It would be more complete if it explicitly directed agents to logout_all for the all-providers case, but that gap is not severe.

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 parameters are already well documented. The description mostly restates what the schema says about provider values and mcp_session_id fallback; it adds no new parameter mechanics or format details beyond that.

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 ('연결을 해제합니다', disconnects) with a specific resource: a named provider connection within an MCP session, and enumerates the valid provider values (SAINT, LMS, LIBRARY). This clearly differentiates it from the sibling logout_all, which applies to all providers.

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 implies usage by saying a provider is required and explaining the mcp_session_id fallback behavior, so an agent can infer 'use this to disconnect one specific provider.' However, it never explicitly names logout_all as the alternative for logging out of all providers, nor does it state when not to use this tool.

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?

The description adds valuable behavioral context beyond the annotations: the current reservation is auto-fetched, no reservation number is needed, the action is two-phase and requires confirm_action, and a LIBRARY-logged-in session is needed. This meaningfully clarifies the non-readOnly, non-idempotent prepare flow. It does not describe failure/error behavior, but it is reasonably transparent for a prepare tool.

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 sentences, each with distinct value: the core action, the automatic reservation lookup, and the confirm_action/auth requirement. The description is front-loaded and contains no filler.

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 description covers the core workflow and auth precondition, but there is no output schema and the prepare-to-confirm handoff is left implicit. An agent is not told what this tool returns or how that result should be passed to confirm_action. It also does not state what happens if there is no current reservation to cancel.

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?

The schema already covers the sole parameter at 100%, so the baseline is 3. However, the description says 'mcp_session_id 필요(LIBRARY 로그인)' while the schema explicitly marks mcp_session_id as optional with a transport-bound session fallback. This is misleading: an agent may treat an optional parameter as required based on the prose.

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 ('반납합니다' - return/cancel) and a specific resource ('숭실대학교 중앙도서관 현재 예약된 좌석'). It also clarifies that the current reservation is looked up automatically, which distinguishes this cancellation path from sibling reserve/swap/waitlist 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?

It gives clear context: use when the user wants to return or cancel their currently reserved library seat. It also explicitly states that this tool alone does not execute the cancellation and that confirm_action must be called, plus notes the LIBRARY login requirement. However, it does not explicitly name alternative tools or state when not to use it.

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?

Beyond the annotations, it discloses that over-limit or unsupported files are automatically excluded and announced, that LMS login is required via mcp_session_id, and that the tool only prepares queue registration rather than performing the export itself. It does not describe side effects or return shape, but the annotations already provide idempotency/read-only/destructive hints.

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 compact and every sentence earns its place: purpose, usage precondition, parameter sourcing, exclusion behavior, and authentication requirement are all covered. There is no filler or redundant restatement of the tool name.

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 description provides enough to invoke the tool correctly, including what to pass and where the values come from. However, there is no output schema and the description does not explain what the tool returns or how to proceed to the likely next step, confirm_lms_material_export, which leaves the full workflow slightly incomplete.

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 baseline is 3. The description adds meaningful provenance for content_ids by saying they come directly from get_my_lms_courses and that get_my_lms_materials need not be called again. The statement 'mcp_session_id 필요' is slightly inconsistent with the schema's optional bound-session fallback, but the parameter is otherwise well covered.

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 action (validates and prepares queue registration) for a specific resource (LMS weekly materials of a user-selected course). It also frames itself as the basic flow for a specific-course download, which distinguishes it from export_all_lms_materials and confirm_lms_material_export.

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 gives a clear call sequence: show get_my_lms_courses results to the user, let them choose a course, then pass that response's content_ids. It explicitly tells the agent not to re-call get_my_lms_materials. It does not explicitly name sibling alternatives like export_all_lms_materials or confirm_lms_material_export, so the exclusion guidance is incomplete.

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?

Beyond annotations (readOnly=false, destructive=false), the description reveals the non-final nature of the prepare step, the need for a LIBRARY-login session, and the expected seat_id source. This is useful behavioral context; it doesn't state side effects like seat-hold expiry, but doesn't contradict 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?

Four sentences, each carrying distinct information: purpose, confirm_action requirement, seat_id/mcp_session_id mapping, and the direct-reservation alternative. It is front-loaded and compact, though slightly denser than necessary.

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 description covers prerequisites and workflow, but because there is no output schema it does not say what the tool returns or how confirm_action picks up the prepared reservation. An agent may not know whether it must pass a prepared action ID or simply call confirm_action with the same session. That missing link prevents full completeness.

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 already documents both parameters (100% coverage), so baseline is 3. The description adds value by mapping seat_id to recommend_library_seats' externalSeatId and giving a concrete example, plus an alternative source (URL number). mcp_session_id is described as needed in the description while schema marks it optional with fallback, a mild wording tension.

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+resource: prepares a central library seat reservation at SSU Campus. It also clarifies that the tool is only a preparation step and does not execute the reservation, distinguishing it from sibling confirm_action and other prepare_* 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?

Clearly tells the agent that final execution requires a separate confirm_action call, and instructs where to source seat_id (recommend_library_seats externalSeatId, or the URL number on oasis.ssu.ac.kr when reserving directly). It doesn't explicitly contrast with prepare_swap_library_seat or prepare_cancel_library_seat, so it falls short of full when-not guidance.

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 declare readOnlyHint=false and idempotentHint=false, and the description adds meaningful context beyond these: it automatically fetches current reservation info (so charge_id is unnecessary), and most importantly, the swap does not execute with this tool alone — confirm_action must be called. This two-phase behavior is foundational for the agent to invoke the tool correctly and is not encoded in 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?

Five short Korean sentences, each earning its place: core action, auto-lookup behavior, confirm_action requirement, alternative routing, and session requirement. The purpose is front-loaded in the first sentence with no redundant filler, though the session note slightly overlaps with the schema's mcp_session_id documentation.

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 moderate-complexity tool with no output schema, the description covers the essential workflow constraints: the two-phase execution, the alternative tool, and the session/login requirement. However, it omits what the tool returns — an agent needs to know the output shape to pass to confirm_action — and it doesn't clarify whether the current seat return is provisional until confirmation, which is material for a state-changing operation.

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 fully documents both new_seat_id (including where to find it) and mcp_session_id (including fallback behavior), setting the baseline at 3. The description adds only marginal parameter context: the note that charge_id is not needed clarifies the parameter surface, and the 'mcp_session_id 필요(LIBRARY 로그인)' note reinforces the session requirement, but neither adds substantial meaning beyond the schema.

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+resource: it automatically returns the current reserved library seat and changes to a new one. It clearly distinguishes itself from siblings, explicitly saying to use prepare_reserve_library_seat when there is no current reservation, which differentiates it from the related prepare_* tools without requiring schema inspection.

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 gives an explicit when-not condition and names the alternative: '현재 예약이 없으면 prepare_reserve_library_seat를 사용하세요.' It also discloses the critical two-phase protocol (must call confirm_action for final execution) and the LIBRARY login requirement. However, it doesn't explicitly state the positive trigger condition (e.g., verify a current reservation exists first) or suggest checking get_my_library_seat to confirm reservation status before use.

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?

Beyond the readOnly/idempotent/destructive annotations, the description discloses that the tool merges real-time availability with the static library/seat-catalog.json, defines the tri-state boolean preference semantics (true=prefer, false=avoid, null/omitted=no preference), states that graduate-only rooms are excluded by default, and requires a LIBRARY-authenticated session. These are meaningful behavioral traits an agent could not infer from annotations or schema alone.

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 information-dense and front-loads the core purpose before any secondary guidance. Every sentence earns its place, though it is a single run-on paragraph that could be bulleted, and the read-only claim and mcp_session_id note partially duplicate what annotations and the schema already state.

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 10-parameter tool with no output schema, the description thoroughly covers input semantics, the graduate-only default, authentication requirements, and the downstream workflow with prepare_reserve_library_seat. The main gap is the return value: the description never indicates what the ranked recommendation list contains or how a chosen seat should be forwarded to the reservation step, which matters more here because no output schema exists.

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 baseline is 3. The description adds value by explaining the null/omitted meaning for all preference booleans (not in the schema), the default-exclusion rule behind include_graduate_only, and the LIBRARY login requirement tied to mcp_session_id. The added meaning is useful but modest because the schema already documents each parameter individually.

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 names a specific verb (순위화합니다 / ranks), a specific resource (currently reservable library seats at SSU Campus), and a specific method (based on user preferences), which sets it apart from sibling tools like get_library_available_seats, get_library_seat_status, and get_library_seat_catalog. It also explicitly names prepare_reserve_library_seat as the downstream step, so the tool's role in the reservation workflow 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?

The description provides explicit workflow guidance: prepare_reserve_library_seat should only be called after the user selects a recommended seat, and include_graduate_only=true should only be used for graduate students since graduate-only reading rooms are excluded by default. It does not explicitly contrast with the status/catalog siblings, so an agent must infer when to prefer this ranking tool over get_library_available_seats or get_library_seat_status.

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?

The annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description goes beyond this by disclosing that live requests are attempted and reported for success, that cached results may be returned, and that original/seed sources and query timestamps are separated in the response. This materially improves an agent's understanding of runtime behavior.

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 two sentences, front-loads the core purpose, and uses the second sentence to convey response characteristics. Every clause adds useful information without redundancy or filler.

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 description covers the search source, the kind of content searched, and high-level response structure (live attempt/success, cache, source, timestamp), which is helpful given there is no output schema. It stops short of naming exact output fields or pagination behavior, but the parameter schema and annotations cover much of the remaining context.

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 all four parameters are already documented with meaningful descriptions. The tool description adds only limited parameter-related context (e.g., the live/cache distinction), but does not need to compensate for missing schema information.

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 clearly states a specific action: searching official Soongsil University regulation and academic guide pages for policy basis paragraphs related to academic rules, graduation, and scholarships. It is distinct and informative, though it does not explicitly contrast itself with similar sibling tools such as list_academic_policy_sources or get_academic_policy_brief.

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?

Usage is implied by the search scope: this tool is appropriate when policy evidence paragraphs are needed from official academic sources. However, the description never explicitly states when to prefer this tool over alternatives, or when not to use it, so the guidance relies on inference rather than direct instruction.

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?

Behavior beyond annotations is disclosed: partial matching across facility name, location, operating hours, phone number, and aliases, plus the empty-query full-list behavior. Annotations already cover read-only, idempotent, non-destructive characteristics, so the description adds meaningful behavioral context without contradiction.

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 two compact Korean sentences with no filler. It front-loads the tool's purpose and then states the important empty-query behavior, making every sentence valuable.

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 simple read-only search tool with no required parameters and no output schema, the description is operationally sufficient: it specifies the facility domain, partial-match behavior, and empty-query fallback. Pagination details are left to the schema, which is acceptable given the low complexity.

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 input schema already documents all three parameters and their semantics. The description adds a small amount of detail by listing operating hours and phone numbers as searchable fields, but it mostly echoes the schema, so the baseline score of 3 is appropriate.

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 names a specific verb and resource: it searches Soongsil University campus facility information such as restaurants, cafes, convenience stores, and bookstores. This clearly distinguishes it from sibling search tools like search_library_book or search_notices.

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 establishes clear context: use this tool to search campus facility information with partial matching, and when query is empty it returns all facilities. It does not explicitly name alternatives or exclusions, but the facility scope is concrete enough for an agent to route requests correctly.

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, and destructiveHint=false. The description adds partial-match search behavior and response contents (title, author, call number, location, availability) plus pagination metadata. This adds context beyond annotations without contradicting them.

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 concise sentences front-load the main purpose, then cover response contents, search matching behavior, and read-only/action separation. No filler words.

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 description is complete for a search tool: it covers purpose, response contents, pagination metadata, search matching, and read-only status. With annotations covering idempotency and no output schema, the main remaining gap is not explaining page/size defaults in prose, but those are already in the input schema.

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 schema documents all parameters well. The description adds useful search semantics: partial matching on title/author/publication info, which clarifies how the query parameter behaves. Slightly less than a 5 because some parameter details are already fully in the schema.

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 resource ('숭실대학교 중앙도서관 소장 도서를 키워드로 검색합니다'), lists the returned fields, and distinguishes itself from sibling tools like borrow/reserve actions. It clearly tells the agent what this tool does and what it returns.

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 explicitly notes that this is read-only and that loan/reservation actions are separate tools, which helps route usage. However, it does not explicitly name sibling alternatives or give when-not-to-use conditions beyond the separation of actions.

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, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond the schema, such as searching both title and body, restricting to a category when provided, and compact output mode affecting the returned fields.

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 three concise sentences with no redundant filler. It front-loads the core search behavior before adding filtering and output-format options, making the tool's purpose immediately clear.

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 read-only keyword search tool with full schema coverage and strong annotations, the description covers the essential behavior, filtering, and output modes. The absence of an output schema is partially mitigated by the compact vs. default return explanation, though response ordering or result limits are not mentioned.

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?

Although schema description coverage is 100%, the description adds semantic value: keyword targets title/body, category restricts the search scope, and compact=true changes the response shape. It does not add much for page, but the schema already documents it.

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 clearly states a specific action (search) on a specific resource (Soongsil University notices), noting that notices containing the keyword in title or body are returned. This differentiates it from sibling tools like get_recent_notices and get_active_notices, which are list-oriented rather than keyword-search oriented.

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 conveys that this tool is for keyword-based notice search and explains how the category filter narrows results. However, it does not explicitly state when to prefer this tool over siblings such as get_recent_notices, get_active_notices, or get_notice_detail, nor does it mention any exclusions.

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?

Beyond the readOnly/idempotent annotations, the description adds meaningful behavior: it restricts input to authenticated records, specifies Soongsil University's 4.5 scale, and states P/F credits are excluded from the denominator. It also flags the SAINT login/session requirement. The 'mcp_session_id 필요' phrase is slightly ambiguous against the schema's optional mcp_session_id, but it does not contradict 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 compact and information-dense, covering purpose, modes, grading scale, exclusions, and authentication in a few short sentences. The primary action is front-loaded, and every sentence earns its place without filler.

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 description is nearly complete for a read-only, idempotent simulation: it names the source record, all parameter modes, scale, exclusions, and auth context. It stops short of describing the returned shape or the meaning of using both modes simultaneously, which is a small real gap given there is no output schema.

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 adds value above the schema by explaining how plannedCredits combines with plannedGradePointAverage or targetGpa and by defining credit semantics (P/F excluded). This gives the agent the calculation logic rather than just field ranges.

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 action and object: simulating cumulative GPA from an authenticated student's u-SAINT academicRecord. It also names the two computation modes (plannedGradePointAverage vs targetGpa), which clearly separates this planning tool from read-only grade retrieval siblings like get_my_grades. This goes well beyond the tool name, so an agent knows exactly what the tool does.

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 explicitly maps use cases to parameters: plannedGradePointAverage with plannedCredits for expected GPA, targetGpa for required average, and both as a valid combination. This is clear within-tool usage guidance, though it does not invoke any sibling tool or state when not to use this tool.

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 provide readOnlyHint=false and idempotentHint=false, signaling a state-changing, non-idempotent operation. The description adds meaningful context beyond this: calling without mcp_session_id creates a new MCP session, the tool returns loginUrl and mcpSessionId, and the original auth call must be retried with the session ID. No contradiction with 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?

Purpose and trigger condition are front-loaded, followed by a numbered 4-step procedure. The length is justified by the interactive nature of the auth flow; every sentence contributes meaning and there is no filler.

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 correctly carries the burden of explaining return values — it names loginUrl and mcpSessionId and specifies exactly how each must be used in the full invoke→show→wait→retry loop. Minor gaps like timeout or error behavior don't prevent correct invocation.

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% — both provider (with per-provider data examples) and mcp_session_id are documented in the schema. The description adds the critical behavioral role of mcp_session_id in the retry flow, which the schema alone does not convey, justifying a score above the baseline.

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 resource: it generates browser login URLs for designated SSU Campus providers (SAINT, LMS, LIBRARY). This clearly differentiates it from siblings like get_auth_status (status check) and logout_provider (session termination), so an agent can distinguish them without inspecting schemas.

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 trigger condition is explicit: '인증 도구가 AUTH_REQUIRED를 반환할 때 이 도구를 사용하세요' (use when the auth tool returns AUTH_REQUIRED), followed by a detailed 4-step procedure including a specific prohibition on substituting the loginUrl with other markdown links. It lacks explicitly named alternative tools, but the invocation context is clear.

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?

Beyond the annotations, the description discloses the most important behavioral trait: this call is user consent, and a server worker may automatically reserve a matching seat without any subsequent confirm_action. It also makes the background nature and session/login requirement explicit, which annotations alone do not convey.

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 dense sentences front-load the core purpose and then add the critical consent and auto-reservation caveat. There is no filler, repetition of schema fields, or unnecessary detail.

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 background-registration tool with no output schema, the description sufficiently covers invocation semantics: what it does, what side effects occur, and the session requirement. It does not describe the return value or how to check/cancel the wait, but the core calling context is complete given the rich schema and annotations.

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 adds only that mcp_session_id requires a LIBRARY login, which is useful context but slightly conflicts with the schema marking that parameter as optional. No additional meaning is added for the other five parameters.

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 action: registering a background wait intent for library seats, and clearly distinguishes itself from sibling tools by noting that it leads to automatic reservation without a confirm_action call. This is a concrete verb+resource combination that separates it from prepare_reserve_library_seat and reservation flow 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?

It gives clear context on when to use this tool: when the user wants to wait for a matching seat and consents to automatic reservation without further confirmation. It also states the prerequisite of a LIBRARY login session. It does not explicitly list alternative tools or exclusion cases, but the contrast with confirm_action provides strong implicit guidance.

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