ssuMCP

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

Annotations already mark destructiveHint=true. Description adds the condition 'if it has not started reserving,' which discloses the limitation that cancellation may not work if the reservation has already started. This adds value beyond 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. First sentence states the action and condition, second states the prerequisite. Efficient and well-structured.

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?

No output schema, but for a simple cancellation operation, the description is sufficient. An agent would understand the tool's purpose and prerequisites. Could optionally mention return values, but not required.

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 description reiterates the parameter's link to start_auth(LIBRARY). While it adds minimal extra meaning, it confirms the parameter's role.

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 clearly states the verb 'cancel' and the resource 'active library seat wait intent', with a condition 'if it has not started reserving'. This distinguishes it from sibling tools like wait_for_library_seat and get_library_wait_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?

Description explicitly states the prerequisite: requires mcp_session_id linked with start_auth(LIBRARY). This provides clear context for when to use the tool, though it does not explicitly mention alternatives or when not to 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that authentication via SAINT is required and that an AUTH_REQUIRED response occurs if not linked, providing behavioral context beyond 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: first states purpose, second states a key requirement. No unnecessary 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?

For a simple read tool with no output schema, the description adequately details the return value and the authentication requirement, making 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% with a description for mcp_session_id. The description adds meaning by explaining the linkage requirement and the AUTH_REQUIRED response, going 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 tool returns 'the authenticated student's u-SAINT graduation eligibility and requirement status', using a specific verb and resource. It distinguishes from sibling tools which handle notices, meals, library, etc.

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 requires 'mcp_session_id with the SAINT provider linked via start_auth', providing clear context for when to use. However, it lacks explicit guidance on when not to use or alternatives.

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 indicate readOnlyHint=true, consistent with description. Description adds behavioral details like optional live fetch and seed corpus search.

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 without wasted words, effectively front-loading the core purpose and key usage 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?

Covers main purpose and key parameters. Lacks mention of return format, but given no output schema, the description is reasonably complete for a query 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 provides 100% coverage of parameters. Description adds minimal extra context beyond schema, noting that evidence may differ per scholarship.

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 clearly states the tool checks scholarship policy against official regulations based on user input, and distinguishes from get_my_scholarships for personal 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?

Explicitly recommends using get_my_scholarships together for personal history, giving clear context. Does not explicitly state when not to 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?

Annotations already declare readOnlyHint=true, so safety is clear. The description adds that the tool classifies and recommends, but does not describe how classification works or any dependencies. With annotations covering safety, 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?

A single, well-structured sentence that conveys the tool's purpose and output clearly without any wasted 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?

Despite no output schema, the description sufficiently explains the output (classification and tool recommendation) and the single input. For a classification tool with clear intent, this is largely 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% for the single parameter 'query', which has a description and example. The description adds no further parameter meaning beyond the schema. 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 the tool classifies academic questions into specific intents (graduation/scholarship/schedule/general regulations) and recommends a next ssuMCP tool. This distinguishes it from sibling tools that perform specific queries rather than 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 implies usage for routing academic questions but does not explicitly state when to use this tool versus alternatives, nor when not to use it. No exclusions or context 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 (readOnlyHint=false, destructiveHint=false) indicate a write operation that is not destructive. The description adds context by explaining that different preparation actions are handled via different mechanisms (queue vs. direct execution). However, it does not disclose potential side effects, error states, or idempotency. Given annotations provide minimal transparency, the description partially compensates.

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 with three short sentences. The first sentence front-loads the primary purpose. The second provides execution nuances for different preparation actions. The third states the authentication requirement. No unnecessary words or repetition.

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 tool's simplicity (confirming an action), the description covers the main purpose, execution differences between preparation actions, and auth requirement. It does not describe return values or error handling, but these may be implicit. With no output schema, the description is mostly complete, though it could mention what happens if there is no pending action.

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 has 100% coverage with a description for the only parameter (mcp_session_id). The tool description repeats the requirement that the session ID must be from the LIBRARY provider via start_auth, adding no new semantics beyond the schema. Baseline 3 is appropriate since schema already documents the parameter well.

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 that the tool confirms and executes the most recent user approval pending action, using specific verbs ('confirm' and 'executes'). It distinguishes itself from sibling preparation tools by being the final step, and mentions specific preparation actions (prepare_reserve_library_seat, prepare_cancel_library_seat, prepare_swap_library_seat) and their execution methods.

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 states when to use this tool: after a prepare_* action has set up a pending action. It notes that some actions are queued and others executed directly, providing context on the usage flow. It also requires mcp_session_id with the LIBRARY provider. However, it does not explicitly state when not to use it or what happens if no pending action exists.

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=true and destructiveHint=false, and the description adds behavioral details: it returns combined status and policy, supports live vs. cache fetch via 'live' parameter, and returns AUTH_REQUIRED if session missing. No contradictions.

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 focused sentence in Korean plus a prerequisite note, front-loading the core purpose. No extraneous 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?

The description covers the return content (status + policy) and the live/cache behavior, but lacks detail on how the 'question' parameter is used (free-text query?) and the output format. Adequate but not rich.

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%, with each parameter documented in the schema. The tool description adds minimal semantic value beyond the schema, so 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 clearly states it returns the u-SAINT graduation requirement status and official regulations/policy basis, distinguishing it from sibling tools like check_graduation_requirements (status only) and get_academic_policy_brief (policy only).

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 mentions the prerequisite of having an authenticated SAINT session, but does not explicitly guide when to use this tool versus the siblings (e.g., when both status and policy are needed). Usage is implied but not contrasted.

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 safety is covered. The description adds filtering behavior but no additional behavioral traits like response format or pagination, which would be expected beyond schema.

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 only two sentences, front-loaded with the main function, and every word adds value. No wasted 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?

Given the tool's simplicity (4 optional params, no output schema, no nested objects) and the presence of annotations and schema, the description is mostly complete. It could mention default behavior for year, but the schema covers that.

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 filter parameters without adding new meaning or usage details 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 tool returns academic calendar events with filtering by year, month, and keyword, and provides specific examples like course registration and exams, distinguishing it from siblings such as get_academic_calendar.

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 context by mentioning use cases (e.g., searching for registration, semester start/end), but does not explicitly state when not to use it or mention alternatives among the many sibling tools.

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 safety profile is clear. Description adds that it returns a list of objects, which is useful context, but does not disclose any additional behaviors like rate limits or data freshness.

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-load the core purpose and return format, with no redundant words. Every sentence adds value.

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 one optional parameter and no output schema, description covers functionality well: specifies return structure, default behavior. Minor gap: doesn't mention time period scope (e.g., full year?), but 'academic calendar' implies annual scope. Essentially 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% with a single optional year parameter described. Description repeats '생략 시 현재 연도' which is already in schema description, adding no new semantic value beyond what the 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?

Description clearly states the tool retrieves the Soongsil University academic calendar, specifies the return format as a list of objects with date, event, and category fields. It distinguishes from sibling tools like get_my_schedule which is personal, and no other sibling seems to cover academic calendar.

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?

Description explains that omitting year defaults to current year, but provides no guidance on when to use this tool versus alternatives. No explicit when-not or cross-references to 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 indicate readOnlyHint=true and destructiveHint=false. Description adds that it returns evidence with source URL, revision history, and live/fallback status, which provides useful behavioral context beyond 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. First states purpose, second clarifies output format. No unnecessary 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?

Given the tool's complexity (4 parameters, no output schema), the description explains return format partially (source URL, revision history, status) but lacks detail on parameter usage (e.g., when to set live or category) and does not differentiate from siblings.

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 parameters are already documented. Description does not add significant extra meaning beyond mentioning live/fallback status, but it is not misleading.

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 clearly states it returns source-based evidence summaries for academic questions, distinguishing from direct answers. However, it does not explicitly differentiate from sibling tools like check_graduation_requirements or check_scholarship_policy, which may also provide evidence but are more specific.

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 on when to use this tool versus alternatives. Does not specify when to prefer this over siblings, nor conditions for using parameters like live or category.

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 clear. The description adds the key behavioral trait of filtering for active notices, which is useful context beyond 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 consists of two concise sentences that are front-loaded with the core purpose. Every sentence adds value with no extraneous 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 tool with one optional parameter and no output schema, the description explains the return filter and use case adequately. It could mention ordering or pagination, but is mostly 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?

The input schema has 100% coverage with a description for the optional 'category' parameter. The tool description does not add any additional meaning beyond what the schema already provides, so 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 clearly states the tool returns only active (pre-deadline) notices and explains its utility for checking imminent or currently applicable notices. This verb+resource combination distinguishes it from sibling tools like get_recent_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 provides clear context for when to use the tool (checking active notices). However, it does not explicitly state when not to use it or mention alternatives, which would strengthen 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?

Beyond readOnlyHint annotation, it discloses session persistence in server memory and reset on restart, and behavior when session ID is missing/invalid. No contradictions.

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 with no waste, front-loaded with purpose, then usage guidance, then behavioral details. Highly efficient.

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 status check tool with no output schema, the description provides sufficient behavioral context, usage guidance, and parameter semantics. No gaps.

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 covers 100% of the parameter with a description, and the tool description adds context about the effect of absent/invalid session ID, adding value beyond 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 tool returns MCP auth session status for each provider (SAINT, LMS, LIBRARY) and explicitly distinguishes it from siblings by advising to call before private tools to avoid AUTH_REQUIRED retries.

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 when to use (before private tools with a session ID) and when not (missing/invalid session) and alternatives (re-auth via start_auth if session lost).

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 readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. It adds no additional behavioral context beyond the basic function, which is acceptable for a read-only 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?

Single sentence with essential information, no wasted words. The department example list is concise and helpful.

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 list tool with complete schema coverage and clear annotations, the description is adequate. It lacks details about return format but no output schema exists, so the burden is low.

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's mention of department examples does not add significant meaning beyond the schema. The page parameter is not elaborated, but the schema already describes 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?

Description clearly states the tool returns notices for a specific department, using the Korean verb '반환합니다'. It distinguishes from siblings like 'get_recent_notices' and 'search_notices' by specifying department filtering.

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?

Description provides examples of department names but does not explicitly state when to use this tool versus alternatives. Usage is implied through the department filter, but no when-not or alternative guidance is given.

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 description adds value by specifying the return includes 7 days of meals and holiday info. No contradictions, and the description adequately discloses the tool's behavior beyond 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, well-structured sentence in Korean that conveys all necessary information without waste.

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 no parameters and no output schema, the description fully explains what the tool does and what it returns. It is complete for a simple read-only query 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?

No parameters exist, so schema coverage is 100%. The description adds context about what is returned (7 days, meals, holiday info), which is useful beyond the empty 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 it queries the weekly menu of the residence hall cafeteria, returning 7 days of breakfast/lunch/dinner and closed days. The verb '조회합니다' is specific, and it distinguishes from sibling tools like get_meal_by_date and 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 does not explicitly state when to use this tool vs alternatives. While the purpose implies it for weekly overview, no direct guidance is provided for choosing between this and similar tools like get_meal_by_date or get_today_meal.

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 important behavioral traits: it may use STT (implying computation time) and warns of delays. This informs the agent of potential latency, which is not captured in annotations 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 concise (3 sentences) and front-loaded with the main purpose. It includes necessary details without fluff. The structure is logical: purpose, mechanism, note on delay, and prerequisite. One minor improvement could be separating the warning for clarity, but overall it is well-structured.

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 complexity (no output schema, no nested objects), the description covers usage and behavior adequately but omits what the returned transcript looks like (e.g., format: plain text, SRT?). An agent may need to know the output format to process it further. However, for a simple retrieval tool, this gap is moderate.

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% with descriptions for both parameters. The description adds value beyond schema by explaining how to obtain content_id (from get_my_lecture_list or LMS URL) and that mcp_session_id is required with LMS provider. This enriches parameter understanding.

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 function: return subtitles or STT text for video lectures. It specifies the fallback mechanism (professor subtitles vs. Groq Whisper AI) and how to obtain the content_id, making the purpose highly specific and actionable. No sibling tool serves this purpose, so differentiation is clear.

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 usage context: it is used when a lecture transcript is needed, mentions potential delay (STT may take minutes), and indicates a prerequisite (mcp_session_id with LMS provider required). It does not explicitly list alternatives or when not to use, but the guidance is sufficient for an AI agent to decide appropriately.

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 agent knows this is a safe read. The description adds behavioral context: away seats are included and externalSeatId is used for reserving seats. The return fields are listed, although no output schema 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?

Four sentences, front-loaded with purpose, each sentence adds value. No redundancy or fluff. Efficient.

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 tool's low complexity (1 param, no output schema), the description adequately explains the return values (count, externalSeatIds, seat numbers, away status). It references usage in another tool and authentication requirement. Complete for its purpose.

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 has one parameter, mcp_session_id, with a clear description. Schema coverage is 100%, so the description adds no extra parameter meaning. 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 clearly states the tool queries real-time available seats across all 7 library reading rooms. It specifies the output includes seat count, externalSeatId, seat numbers, and away status. It distinguishes from sibling get_room_available_seats for detailed room info.

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 explicit context: use this for an overview of all rooms, then use get_room_available_seats for specific room details. It also states the prerequisite of having an mcp_session_id from start_auth(LIBRARY).

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?

Discloses static nature, no authentication required, and highlights that data is from screenshots. Adds context beyond annotations (readOnlyHint=true, destructiveHint=false) by describing data source 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?

Two sentences with no fluff. Key information is front-loaded: static catalog, no live availability, authentication not required. Every sentence is essential.

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?

Adequately describes purpose and key traits for a static read-only query tool. Without output schema, it's sufficient given sibling tools handle live data. Could mention the output type (e.g., JSON structure) for 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 covers 100% of parameters with individual descriptions. Description adds value by explaining when to use include_layout, providing usage context beyond schema definitions.

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 clearly states it returns a static library seat catalog built from screenshots, distinguishing it from live-seat tools like get_library_available_seats. The verb 'Returns' specifies the action and 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?

Explicitly notes it does not include live availability, guiding against using for real-time queries. Mentions specific use case for include_layout. However, could further clarify when to choose this over sibling tools like 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that the tool returns AUTH_REQUIRED with a loginUrl if LIBRARY is not authenticated, and explains the response structure (floor summary or zone details). This provides value beyond annotations 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?

Description is concise and front-loaded with the main action. It uses mixed Korean and English, which is acceptable but may slightly reduce clarity for English-only agents. Every sentence adds value, with no wasted 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?

Given no output schema, the description explains the response content (floor summary or zone details) and the authentication failure case. It is fairly complete for a read-only tool with a well-explained parameter set, though it omits potential pagination or rate limits.

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 descriptions in schema are clear. The description adds meaning by explaining compact behavior ('compact=true returns only total/available/reserved counts') and the mcp_session_id authentication flow. This enhances understanding beyond the schema alone.

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 clearly states the tool retrieves current seat status by floor, with specific details on total/available/reserved/unavailable seats and zone distribution. It distinguishes itself from sibling tools like get_library_available_seats and prepare_reserve_library_seat by focusing on viewing status and noting reservation is separate.

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?

Description provides context: it's read-only, requires LIBRARY authentication, and compacts response via compact parameter. It implicitly advises against using for reservations by stating reservation is handled by separate tools. However, it lacks explicit when-not-to-use scenarios or alternatives beyond the read-only note.

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, confirming a safe read operation. The description adds the requirement that the session must be linked with start_auth(LIBRARY), which is useful context. However, no other behavioral traits (e.g., response format, rate limits) are disclosed, and the description does not 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?

The description is extremely concise at two sentences, with the key action ('Get the latest... status') front-loaded. Every word serves a purpose, and there is no redundancy or fluff.

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 with one parameter and no output schema. The description explains the purpose and the authentication prerequisite, but does not specify what the returned status looks like (e.g., data structure, possible values) or error conditions. Given the lack of an output schema, more detail on the response would improve 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?

The schema has 100% coverage with a clear description for the sole parameter 'mcp_session_id'. The description echoes this requirement ('Requires mcp_session_id linked with start_auth(LIBRARY)') but adds no meaningful new detail beyond what the schema already 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 clearly states the verb 'Get' and the resource 'library seat wait intent status'. It distinguishes itself from siblings like 'wait_for_library_seat' and 'cancel_library_wait' by specifying it retrieves the latest 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 mentions the prerequisite of an mcp_session_id linked with start_auth(LIBRARY), which implies authentication is needed. However, it does not provide explicit guidance on when to use this tool versus alternative sibling tools (e.g., 'get_my_library_seat' or 'wait_for_library_seat'), so the usage context is only partially covered.

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 and non-destructive. Description adds behavioral context: returning all corner menus and holiday info when restaurant is empty. No contradictions.

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, front-loaded with main purpose, no unnecessary words. Each sentence adds distinct value.

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 query tool with well-described parameters, the description fully covers usage scenarios. No output schema needed for menu listing; description suffices.

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 covers 100% of parameters but description adds meaning: exact ISO date format for 'date' and enumerates possible Korean values for 'restaurant'. Also explains empty behavior, which schema doesn't cover.

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 clearly states the action (조회) and resource (숭실대학교 학생식당 메뉴) with specific date format. It distinguishes from sibling 'get_today_meal' by supporting arbitrary dates, and explains behavior based on restaurant parameter.

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?

Description explicitly explains two usage modes: leaving restaurant empty for all restaurants vs. specifying one. It provides clear context on when to use each, but does not mention when not to use this tool or alternatives beyond 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 indicate readOnlyHint=true and destructiveHint=false. The description adds context about the weekly nature and weekOffset behavior but does not disclose additional traits like data freshness, caching, or response format. The added value is moderate.

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, with two sentences covering purpose, parameter behavior, and sibling differentiation. No unnecessary 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?

For a simple read-only tool with one optional parameter and no output schema, the description is complete. It clearly states the tool's function, parameter semantics, and distinguishes it from the dormitory menu 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 fully describes the weekOffset parameter (100% coverage). The description adds significant value by explaining the offset's meaning (0=this week, 1=next week) and the default behavior (Monday to Sunday), which goes beyond the schema's brief description.

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 retrieves weekly menus for the Soongsil University student cafeteria, specifying the date range (7 days). It distinguishes itself from the sibling tool get_dorm_weekly_meal, which is explicitly mentioned for dormitory menus.

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

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

The description explains when to use the tool (weekly menu) and explicitly directs users to get_dorm_weekly_meal for dormitory menus. It also explains the weekOffset parameter's effect (0=this week, 1=next week). However, it does not mention when to avoid it or compare with other meal-related siblings like get_today_meal.

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 descriptions adds behavioral details beyond the readOnlyHint=true annotation, such as returning AUTH_REQUIRED with a loginUrl when LMS is not authenticated, and explaining how to retry. It also clarifies default behavior for term_id.

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 somewhat lengthy and mixes English and Korean text, which may reduce clarity for non-Korean readers. While the first sentence is front-loaded, the mixed language and additional instructions could be condensed.

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 explains error handling and parameter usage well, but lacks details about the return format (no output schema). It also does not define what 'pending' assignments mean. Given the absence of an output schema, more detail on the response structure would improve 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 coverage is 100%, but the description adds value by explaining the compact parameter behavior and the term_id default/alternative retrieval via get_my_lms_terms. This provides guidance not present in 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 clearly states the tool returns 'pending LMS assignments and quizzes' for the authenticated student, using a specific verb+resource format. It distinguishes from sibling tools like get_my_lms_terms which list terms.

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

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

The description explains when to use the tool (requires mcp_session_id from start_auth) and how to handle the term_id parameter. It also provides error handling guidance for missing authentication. However, it does not explicitly state situations where this tool should not be used.

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 readOnlyHint=true and destructiveHint=false. Description supplements with important details: authentication requirement and error response when session is absent or not linked. 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?

Two sentences, each with a distinct purpose: first states core function, second covers optional parameters and auth requirement. No fluff, 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-only tool with 3 parameters and no output schema, description covers purpose, parameters, default behavior, and auth linkage. Could mention return format but not critical.

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 has 100% coverage with descriptions for all 3 parameters. Description adds value by explaining default behavior for year and semester when omitted, which is not in 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?

Description clearly states the tool returns chapel attendance info for the authenticated student, using a specific verb and resource. It distinguishes from sibling tools like get_my_grades or get_my_schedule.

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 context on optional parameters and default behavior (current semester used when omitted). Also states the authentication requirement via mcp_session_id linked through start_auth. Does not explicitly exclude alternatives but 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 declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the auth requirement and that AUTH_REQUIRED with loginUrl is returned if not authenticated. This goes beyond the annotations to provide behavioral context for error handling.

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: first states purpose, second states requirement, third explains error recovery. Every sentence is necessary and front-loaded. No wasted 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?

For a tool with one parameter and no output schema, the description is fully complete. It covers purpose, input requirement, error scenario, and user action. No obvious gaps.

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?

There is one required parameter (mcp_session_id) with 100% schema description coverage. The description adds meaning by explaining that if the parameter is absent or SAINT not linked, the tool returns AUTH_REQUIRED with a loginUrl. This enhances the schema's description.

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 authenticated student's cumulative u-SAINT grades including semester GPA history. It specifies a concrete action ('returns') and a resource ('u-SAINT grades'), which distinguishes it from sibling tools like get_my_schedule or get_my_library_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 explicitly states the required mcp_session_id from start_auth and provides step-by-step instructions for handling the AUTH_REQUIRED error: show loginUrl to user and retry. It does not mention when to use this tool over alternatives like check_graduation_requirements, but the context is clear enough for the intended 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 indicate readOnlyHint=true and destructiveHint=false. The description adds important behavioral details: requires mcp_session_id with LMS provider, and returns AUTH_REQUIRED if not authenticated. This complements annotations well.

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-loaded with the main purpose, then providing key details (return fields, parameter behavior, authentication). 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?

Despite no output schema, the description specifies return content (content_id, title, week info). It addresses authentication and session requirements completely for a read-only list tool in this 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 has 100% description coverage for both parameters. The description adds value by explaining term_id default behavior and that mcp_session_id must be linked via start_auth. It also highlights that content_id is used for get_lecture_transcript.

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 video lecture lists from LMS with content_id, title, and week info. It explicitly distinguishes from sibling tools like get_lecture_transcript (which uses content_id) and get_my_lms_terms (for term selection).

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: when to use to obtain content_id for get_lecture_transcript, and how to specify term_id or default to current term. It also directs users to get_my_lms_terms for other terms. It lacks explicit 'when not to use' but gives sufficient alternatives.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: the tool may return AUTH_REQUIRED with a loginUrl if not authenticated, and details the correct user-facing flow. 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 two sentences, efficient and front-loaded: the first states the main purpose, the second provides necessary authentication handling. No unnecessary 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?

Given no output schema, the description still explains both success (loans with due dates) and error (AUTH_REQUIRED) behavior. It covers authentication requirements and user interaction steps. Complete for a simple read 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 only parameter mcp_session_id is fully described in the schema (100% coverage). The description does not add extra parameter-specific meaning beyond the schema, but the schema itself is sufficient. Per guidelines, 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 explicitly states 'Returns the authenticated user's current library loans including due dates.' This clearly identifies the verb (Returns), resource (library loans), and scope (authenticated user). It distinguishes from siblings like search_library_book which deals with book search.

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 guidance: it requires mcp_session_id linked via start_auth, and explicitly instructs the agent to show loginUrl to the user and retry if authentication fails. This tells when to use and how to handle authentication errors.

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 discloses that if no seat is reserved, the tool will inform the user accordingly. This aligns with the readOnlyHint annotation and adds context beyond the 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 concise, comprising three sentences that cover purpose, behavior, and usage guidance. It is well-structured and 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?

While no output schema is provided, the description sufficiently explains the output behavior (returns reservation info or informs if none). This meets the needs for a simple read-only 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 single parameter 'mcp_session_id' is well-documented in the schema, and the description reinforces its requirement. With 100% schema coverage, the description adds additional context about the authentication provider.

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 that the tool retrieves the user's currently reserved library seat information. It distinguishes from sibling tools like 'get_library_available_seats' and 'get_library_seat_status' by focusing on the user's own reservation.

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 tells when to use the tool (to check current reservation) and provides alternatives for cancellation ('prepare_cancel_library_seat') and swapping ('prepare_swap_library_seat'). It also notes the prerequisite of having a valid mcp_session_id with the LIBRARY provider.

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 clear. The description adds that it returns a list with specific fields, which is consistent but doesn't provide substantial new behavioral information beyond 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?

Three sentences efficiently cover purpose, return fields, usage, and requirements. No wasted words, front-loaded with the main action.

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 no output schema, the description adequately describes the return structure. Combined with clear annotations and schema, it provides a complete picture for a simple list retrieval 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?

With 100% schema description coverage, the schema already documents the single parameter thoroughly. The description reinforces the requirement but adds no new 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 clearly states it returns a list of LMS registration terms with specific fields (id, name, dates, default term status). It also explains how to use the returned id in get_my_lecture_list or get_my_assignments, distinguishing it from sibling tools that consume these IDs.

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 mentions using the term_id in other tools and notes the requirement of mcp_session_id with LMS provider. It provides clear context for when to use this tool, though it doesn't explicitly state when not to use it or list alternatives.

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 readOnlyHint=true, destructiveHint=false, but the description adds significant behavioral context: it explains the AUTH_REQUIRED error with loginUrl and how to handle it, and the default behavior when year/term are omitted. This goes well beyond what annotations provide.

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 sentences, front-loading the core purpose in the first sentence, then covering behavior details efficiently. Every sentence adds value 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?

Given the tool's simplicity (3 params, one required, read-only, no output schema), the description fully covers what the tool does, how parameters interact, authentication requirements, and error handling. No gaps remain.

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 baseline is 3. The description adds value by stating that year and term must be provided together if used, which is not implied by the schema (both are optional). It also repeats term values, but that's already in schema. Overall, it adds meaningful constraint 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 states 'Returns the authenticated student's u-SAINT timetable grouped by course', which is a specific verb+resource. It clearly distinguishes from sibling tools like get_my_grades or get_my_assignments by focusing on the timetable.

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

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

The description explains when to use the tool (with or without year/term) and prerequisites (mcp_session_id linked via start_auth). It does not explicitly discuss alternatives, but the context is clear. A minor lack of exclusionary guidance prevents 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 and destructiveHint=false. The description adds value by noting the optional year behavior and the AUTH_REQUIRED response when mcp_session_id is missing or SAINT not linked, which aligns 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 two sentences, front-loaded with the main purpose, and contains no superfluous information. Every word 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?

Given no output schema, the description covers prerequisites, optional parameter behavior, and error conditions. It is sufficiently complete for an agent to use the tool correctly, though return format is not detailed.

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 both parameters. The description adds meaning by clarifying the year parameter's optional nature and the implication of returning all history when omitted, and by explaining the mcp_session_id's role in authentication.

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 authenticated student's u-SAINT scholarship receipt history, using a specific verb and resource, which distinguishes it from sibling tools like get_my_grades or get_my_schedule.

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

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

The description explains that the year parameter is optional and that a valid mcp_session_id with SAINT linked via start_auth is required. It provides clear context for use but does not explicitly state when not to use or mention alternatives.

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 clear. The description confirms the read-only nature by stating it returns text, but adds no additional behavioral context beyond what the annotations provide.

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, effective sentence in Korean. It front-loads the purpose and includes essential usage instruction without any filler. Every word 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 tool with one parameter and no output schema, the description is complete. It explains what the tool returns (full text), how to obtain the input (from sibling tools), and implicitly conveys that the output is plain text. No additional information is necessary.

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 covers 100% of parameters, with a clear description for the 'url' field. The description repeats the schema's guidance ('get_recent_notices/search_notices 결과의 link 값') without adding new meaning or format details. 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 clearly states the tool returns the full text of a notice given its URL. It specifies the resource ('본문 전체 텍스트') and action ('반환합니다'), and implicitly distinguishes from sibling tools that list or search notices by requiring a specific URL as input.

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 instructs the agent to pass the 'link' value from get_recent_notices or search_notices results as the input. This provides clear context on when and how to use the tool, effectively guiding the agent away from incorrect usage.

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 (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds that compact=true returns only title/URL, which is hinted in the schema. However, it does not discuss pagination behavior or response structure beyond the schema.

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 extremely concise with three short sentences. The first sentence directly states the purpose, followed by filtering details and cross-reference to another tool. 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?

The description covers the main functionality and references category lookup, but lacks details on the return format (e.g., whether it includes pagination metadata) and pagination behavior. Since there is no output schema, more detail would be beneficial for 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?

The input schema covers all three parameters (page, compact, category) with descriptions, achieving 100% coverage. The description does not add new semantic meaning beyond what is in the schema, so 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 clearly states it retrieves the latest list of Soongsil University notices with optional category filtering, which differentiates it from sibling tools like 'search_notices' that likely perform broader search. However, it does not explicitly distinguish from 'get_active_notices' or 'get_department_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 mentions that categories can be obtained via 'list_notice_categories', which is helpful, but it provides no guidance on when to use this tool versus alternatives like 'search_notices' or 'get_active_notices'. There is no scenario-based advice.

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 read-only and non-destructive behavior. The description adds valuable context: it is real-time, returns specific seat statuses and details, and requires a valid authenticated session. There is no contradiction between the description and 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 four sentences, starting with the primary purpose. It efficiently covers purpose, return fields, room IDs, and auth requirement. No unnecessary information, though the structure could be slightly improved by grouping room IDs in a list format.

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 list tool with no output schema, the description adequately explains the return fields (seat status, label, type, remaining time) and provides necessary context (room IDs, session requirement, link to reservation tool). Given the low complexity, it is complete and informative.

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% with descriptions for both 'roomId' and 'mcp_session_id'. The description repeats the roomId values but adds the room names in Korean, and also mentions the externalSeatId usage, which is not a parameter but relates to the output. The added value over the schema is minimal, so 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 clearly states the tool's action: '실시간으로 조회' (real-time inquiry) of seat status for a specific library room. It lists room IDs and explains the return fields (seat status, label, type, remaining time). It also distinguishes itself from sibling tools by noting that the returned 'externalSeatId' is used in 'prepare_reserve_library_seat', guiding the user to the appropriate reservation tool.

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 prerequisite: 'Requires mcp_session_id with the LIBRARY provider linked via start_auth.' It also indicates when to use this tool (before reservation by mentioning prepare_reserve_library_seat). However, it does not explicitly state when NOT to use it or list alternatives, though the context implies it for room-level seat listing.

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=true, and the description adds context: it describes that empty argument returns all corners' menus and closure info, and specifying a restaurant restricts results. This goes beyond 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, front-loaded with main purpose, no extraneous words. Efficient and 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?

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers behavior for both parameter states and provides all needed 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 coverage is 100% for the single parameter, and the description adds meaning by explaining the effect of empty vs specified values, and lists possible restaurant names. It enhances the schema description.

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 retrieves today's meal from Soongsil University student cafeteria, explains the behavior for empty vs specified restaurant argument, and distinguishes it from sibling tools like get_meal_by_date by specifying 'today'.

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

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

The description explains when to leave restaurant empty (returns all campus restaurants) vs specifying a restaurant (filters). It implicitly differentiates from siblings but does not explicitly state when not to 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context beyond confirming read-only behavior. It mentions checking 'live 지원 여부' which matches the schema parameter, but does not disclose any additional traits like data freshness, authorization needs, or response volume.

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 short paragraph in Korean, efficiently stating the purpose and output fields. It is front-loaded and contains no redundant information. However, it could be restructured with bullet points for better scanability.

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 low complexity (zero required params, simple list operation) and the presence of annotations, the description adequately covers the output fields (URL, contentUrl, revision/effectiveDate, live support, verification date). It also hints that results can be filtered by 'live' and 'category' parameters. Though lacking pagination details, it is sufficient for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters clearly documented. The description repeats some aspects (e.g., 'live 지원 여부') but does not add meaning beyond the schema descriptions. Baseline score of 3 is appropriate as the description does not significantly enhance parameter understanding.

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 a list of official sources queried by the academic RAG, specifying the attributes (URL, contentUrl, revision/effectiveDate, live support, verification date). The name 'list_academic_policy_sources' is specific and distinguishes from sibling tools like 'search_academic_policy_sources' which suggests searching within those sources.

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

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

The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives such as 'search_academic_policy_sources' or other policy-related tools. The context signals include many siblings, but the description lacks usage cues, leaving the agent to infer from context.

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 description adds only the context of returning a list and its relationship to other tools. No additional behavioral details like output format are provided.

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 purpose and usage context are front-loaded and 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?

Given the zero parameters and no output schema, the description is complete enough for a simple category list tool, but it could mention the output type (e.g., names/IDs) without being necessary.

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?

There are no parameters, and schema coverage is 100%. The description adds no parameter details, but with no parameters this is acceptable; baseline 4 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 the tool returns a list of notice categories and explicitly links its utility to the category parameter of sibling tools get_recent_notices and search_notices, distinguishing it from other 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?

The description provides clear context for when to use the tool (to check category values for other tools) but does not explicitly state when not to use it or list alternatives.

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 destructiveHint=true, so the description's 'Removes' and 'fully invalidate' align with it. The description adds the scope ('all linked providers') but does not disclose side effects or irreversibility beyond what annotations imply. Neither contradicts the other.

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 waste. The first sentence states the action clearly, and the second adds the requirement. Information is front-loaded and easy to parse.

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 with one parameter and no output schema. The description covers the action and requirement, but does not mention what the result or response looks like (e.g., success/failure). With siblings like 'logout_provider', a brief comparison would be helpful. Adequate but not thorough.

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 description redundantly states 'Requires mcp_session_id' which is already in the schema with a description. No additional semantics are provided 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 ('Removes') and resource ('entire MCP auth session and all linked providers'), clearly distinguishing it from the sibling tool 'logout_provider' which likely logs out a single provider.

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 states the requirement for mcp_session_id but does not explicitly specify when to use this tool versus alternatives like 'logout_provider' or 'start_auth'. Usage context is implied but not clarified.

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 destructiveHint=true and readOnlyHint=false. The description adds that it 'unlinks' and requires parameters, but no further behavioral details such as side effects, reversibility, or prerequisites.

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 sentence that efficiently conveys purpose and requirements 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?

For a simple tool with two parameters and high schema coverage, the description covers purpose and requirements. Lacks mention of session validity or error states but is adequate given the tool's simplicity.

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% with clear parameter descriptions. The description only restates the requirement for both parameters, adding no extra 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?

Clearly states the action 'unlinks' a specific provider from the MCP session, naming the allowed providers and required parameters. It distinguishes from the sibling 'logout_all' which handles 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 when you need to unlink a single provider given a session ID, but does not provide explicit when-not-to-use or alternatives like 'logout_all'. No exclusions or context for appropriate 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?

Discloses that the tool is not self-executing (requires confirm_action) and automatically queries current reservation. Annotations indicate non-destructive write; description adds valuable workflow context beyond 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?

Three concise sentences, each serving a purpose: main action, automatic querying detail, execution requirement. Front-loaded with core function.

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 simple 1-parameter tool with no output schema, description fully covers purpose, auth requirement, and execution flow. No gaps for agent to infer.

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% for single parameter mcp_session_id, with description. Description reiterates that it requires LIBRARY provider linked via start_auth, adding minor context. No need for further elaboration.

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 clearly states the verb 'cancel' and resource 'library seat reservation' (현재 예약된 좌석 반납). Distinguishes from siblings by noting automatic retrieval of reservation info, implying no manual reservation number needed.

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 mentions two-step process requiring confirm_action and auth requirement via start_auth(LIBRARY). Does not explicitly contrast with alternatives like prepare_swap_library_seat, but provides clear context for when to invoke.

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 (readOnlyHint=false, destructiveHint=false), the description reveals that the tool does not execute the reservation itself and requires confirm_action. It also specifies the authentication requirement, adding valuable behavioral context.

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, front-loaded with purpose, and every sentence provides necessary information without redundancy. It efficiently covers the key points.

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 tool's role in the workflow, authentication needs, and seat_id sources. However, it does not mention the tool's return value, which could be relevant for the subsequent confirm_action call. Slight gap in 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 coverage is 100% with basic descriptions. The tool description adds specific guidance on seat_id source (recommend_library_seats response or manual URL extraction) and a format example, enhancing 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 clearly states the tool prepares a library seat reservation, distinguishes it from the final execution step (confirm_action), and specifies the required authentication. It is specific and 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 explains the two-step workflow (prepare then confirm), the required mcp_session_id from start_auth, and how to obtain seat_id. It does not explicitly exclude alternative tools but provides clear context for when 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?

Description reveals automatic query of current reservation, no charge_id needed, two-step process with confirm_action. No contradiction with annotations; readOnlyHint=false and destructiveHint=false are aligned.

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 in Korean, each providing essential information without redundancy. Front-loaded with main action, then usage guidance, then precondition. No fluff.

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?

While no output schema exists, the description covers behavior and next steps (confirm_action). It lacks return value details but the multi-step context is handled by sibling tools. Sufficient for the 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 coverage is 100% with descriptions. The description adds value by reinforcing that mcp_session_id must be from start_auth(LIBRARY) and that new_seat_id comes from specific tools. Marginally above baseline 3.

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: automatically return current seat and change to a new one. It distinguishes from sibling tools by specifying when to use prepare_reserve_library_seat (no current reservation) and mentions automatic charge_id handling.

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 states when to use (swap existing reservation) and when not (use prepare_reserve_library_seat if no reservation). Also notes requirement for mcp_session_id from start_auth and that confirm_action must be called to finalize.

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?

Reinforces readOnlyHint with 'This read-only tool', explains boolean preference semantics (true/false/null), and notes combination of live and static data. Does not cover edge cases like no matching seats or rate limits.

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, front-loaded with main purpose, no redundancy. Each sentence serves a clear role (purpose, boolean behavior, graduate-only note, next-step reference).

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?

Covers core functionality, preference handling, and next step. With no output schema, could briefly describe expected output format (ranked list of seats), but current description is sufficient given complexity 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 has 100% coverage, but description adds value by explaining boolean preference usage and include_graduate_only default and target audience, which is not fully captured in property 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?

Description begins with 'Ranks currently available Soongsil library seats by user preferences' – a specific verb and resource. Distinguishes from sibling tools like get_library_available_seats by focusing on preference-based ranking.

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?

States when to use prepare_reserve_library_seat after recommendations, and explains default exclusion of graduate-only rooms with condition for inclusion. Lacks explicit comparison to sibling tools for simple availability queries.

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 readonly and non-destructive behavior. The description adds context about live fetching and fallback, which is useful but not detailed enough (e.g., what happens if both fail, response format).

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: purpose first, then behavior for live parameter. No filler, 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?

Given no output schema, the description reasonably covers the tool's scope and behavior. Could mention output format or source fallback limits, but adequate for a search tool with 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% with clear parameter descriptions. The description adds minimal value beyond the schema, only clarifying the live parameter's effect. Baseline at 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 clearly states the tool searches for academic policy paragraphs from official university sources. It names specific subdomains (regulations, graduation, scholarship) but does not explicitly differentiate from siblings like check_graduation_requirements or list_academic_policy_sources.

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

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

The description explains the live parameter behavior ('live=true queries official URL, fallback to seed corpus') but gives no guidance on when to use this tool versus alternatives for graduated or policy checks.

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?

Description discloses partial matching behavior on multiple fields (name, alias, location) and empty-query behavior. Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds operational details 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?

Description is concise: one sentence with two clear clauses, front-loaded with purpose and followed by behavior. No wasted 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?

Given low complexity (1 optional param, no output schema), the description fully covers behavior, parameter semantics, and usage context. No gaps.

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% with description for 'query'. Description adds value by explaining partial matching across fields and full list on empty query, beyond schema's basic type and length.

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 clearly states the tool searches for campus facilities (식당, 카페, 편의점, 서점) with specific verb '검색합니다'. It distinguishes from siblings by focusing on physical facilities, unlike other tools for notices, grades, etc.

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?

Description implies usage for facility search and mentions empty query returns full list, but does not explicitly state when not to use or compare to alternatives. However, the tool's focus is clear from context.

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. The description adds that the response includes title, author, call number, location, and availability, and that search matches partially on title/author/publisher. This provides useful 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 concise—two sentences—and front-loaded with the main action. Every sentence adds value 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?

Given the lack of output schema, the description lists response fields (title, author, call number, location, availability) and mentions partial matching. It covers the main functionality and constraints well for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description does add any additional meaning beyond what the schema already provides for the 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 clearly states the tool searches for books in Soongsil University Central Library by keyword, listing the response fields. This is specific and distinct from sibling tools like search_campus_facilities and 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 explicitly states the tool is read-only and that loan/reservation actions are handled by other tools, guiding when to use it and when not to. However, it does not name the alternative tools explicitly.

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 indicate readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: keyword search spans title and body, category filtering is available, and compact mode alters the response format. 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 three concise sentences in Korean, with the purpose front-loaded. Every sentence adds essential information—search scope, category filter, and compact mode—without unnecessary details.

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?

Despite lacking an output schema, the description outlines the return format for both compact and non-compact modes (titles/URLs vs. with date/category). All four parameters are addressed, and the token limit for keyword is specified. It is sufficiently complete for an agent to use 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%, and the description adds meaning beyond the schema: it specifies that the keyword is searched in title and body, explains the category filter's effect, and clarifies the behavior of the 'compact' parameter. This provides the agent with clearer usage 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 clearly states the tool searches Soongsil University notices by keyword, returning notices containing the keyword in title or body. It distinguishes itself from sibling tools like 'get_recent_notices' or 'get_active_notices' by focusing on keyword search. The mention of category filtering and compact mode further clarifies its scope.

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

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

The description explains that specifying a category limits search to that category, but it does not provide explicit guidance on when to use this tool versus alternatives like 'search_academic_policy_sources' or 'get_notice_detail'. The usage context is implied rather than explicitly 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 indicate readOnlyHint=true and destructiveHint=false, so the description does not contradict them. It adds valuable behavioral context: uses SSU's 4.5 max scale, excludes P/F credits from denominator, and requires mcp_session_id with SAINT provider. These details go 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?

Two concise sentences with no wasted words. The critical information is front-loaded, and every sentence contributes to understanding the tool's purpose and usage.

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 simulation tool: it covers purpose, parameters, scale, and exclusion rules. No output schema exists, but the tool's output (projected GPA or required average) is implied. The requirement for mcp_session_id is clearly stated. A minor gap is not explicitly describing the response format.

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 baseline is 3. The description adds meaning by explaining how plannedCredits interacts with plannedGradePointAverage or targetGpa, and clarifies that plannedCredits exclude P/F credits. This enhances the 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 it simulates cumulative GPA using the academic record, with a specific verb ('simulates') and resource ('u-SAINT academicRecord'). It distinguishes from sibling tools, which are primarily informational or authentication-related, making the tool's unique purpose 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 explains when to use the tool (to project GPA or compute required average) and how to use the parameters (plannedCredits with either plannedGradePointAverage or targetGpa). It mentions the requirement for mcp_session_id. However, it does not explicitly state when not to use the tool or list alternatives, though the uniqueness of the tool makes that less critical.

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?

Discloses session creation and steps. Annotations are minimal (readOnlyHint=false, destructiveHint=false), description adds context such as login URL generation and session ID reuse.

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 is front-loaded in first sentence. Steps are included but could be more concise. Overall well-structured and readable.

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?

No output schema, but description implies return fields (loginUrl, mcpSessionId). Workflow is covered. Sibling tools are many but this tool is unique.

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%, description adds extra details for provider (Korean explanations) and confirms mcp_session_id behavior. Adds value 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?

Clearly states action ('generates a browser login URL') and resource ('specified provider'), and distinguishes from sibling tools like get_auth_status and logout_all.

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 'Use this tool when a private tool returns AUTH_REQUIRED' and provides step-by-step workflow. Could mention when not to use, but the 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?

The description adds important behavioral context beyond annotations: it states that the call is consent and that the server may autonomously reserve the seat without further confirmation. This is valuable for an AI agent. Annotations confirm it is not read-only or destructive, which aligns.

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 with three well-structured sentences: purpose, behavioral implication, and prerequisite. Every sentence adds value and no fluff.

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?

While the description covers the tool's core behavior, it lacks information about what the agent should expect after calling (e.g., success/error responses) and how to manage the wait using sibling tools like cancel_library_wait or get_library_wait_status. It is adequate but incomplete for a tool with 6 parameters and 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 description coverage is 100%, so the schema already documents all parameters adequately. The description does not add additional parameter semantics beyond mentioning 'mcp_session_id' requirement. 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 clearly states the verb 'Register a background wait intent' and specifies the resource 'Soongsil central-library seat'. It distinguishes from sibling tools like prepare_reserve_library_seat by noting that this tool may autonomously reserve without a confirm_action 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?

The description explains when to use this tool (to wait for a seat and have it auto-reserved) and provides a prerequisite (mcp_session_id from start_auth(LIBRARY)). However, it does not explicitly mention alternatives or when not to use it, though the context implies it.

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