ku-portal-mcp
Server Quality Checklist
Latest release: v0.12.0
- Disambiguation5/5
Each tool targets a distinct resource or operation. Notices, grades, timetable, library, LMS functions, etc., are cleanly separated with clear descriptions, making it easy for an agent to select the correct tool.
Naming Consistency3/5All tools share the 'kupid_' prefix, but beyond that, naming patterns vary: some use verb_noun (get_notices), some use area_noun (lms_announcements), and some use noun_noun (dept_notices). This inconsistency, while still readable, could confuse an agent.
Tool Count4/5With 31 tools, the server is fairly comprehensive for a university portal. The count is slightly above the ideal range but justified by the breadth of functionality (portal, LMS, search, etc.).
Completeness5/5The tool set covers nearly all expected operations for a university portal: viewing notices, schedules, scholarships, grades, timetable, library seats, and full LMS integration including courses, assignments, quizzes, submissions, boards, and file downloads. No obvious gaps for the read-only nature of the domain.
Average 3.9/5 across 31 of 31 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it retrieves a list, but does not mention safety (e.g., read-only, idempotent), authentication requirements, rate limits, or any side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single sentence explaining the purpose followed by the parameters. It avoids unnecessary details and is well-structured. However, the parameter list is redundant with the schema, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not explain return values. However, it lacks usage context, such as when to use this list tool versus the detail tool, and does not mention pagination behavior despite having page/count parameters. It is marginally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the two parameters with defaults (page and count), but does not explain their meaning beyond their names. The defaults are already in the schema, so the description adds minimal value. It fails to provide semantic context like usage examples or accepted value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a list of notices from KUPID portal (verb: retrieve, resource: list of notices). However, it does not differentiate from sibling tools like `kupid_get_notice_detail`, which likely retrieves a single notice. A score of 4 reflects clarity but lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparisons to sibling tools like `kupid_get_notice_detail`. The description only explains what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states '조회합니다' (retrieves) without detailing behavior like pagination, empty results, or side effects. Output schema exists but is unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with the main purpose. The parameter documentation is structured clearly in a docstring format. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values are handled. However, missing context about authentication, idempotency, and pagination behavior beyond defaults makes it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. It explains page and count with defaults, which adds value but lacks additional semantics like max page size or indexing (1-based). Minimum viable compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb '조회합니다' (retrieve/list) and resource '장학공지 목록' (scholarship notice list). It is distinct from sibling tool kupid_get_scholarship_detail which is for details. However, it doesn't explicitly mention it's a list tool or contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites, required authentication, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states that it retrieves details, with no mention of side effects, authentication requirements, or other notable behaviors. This is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, but the structure is minimal. It consists of a single sentence and an 'Args' list, which is adequate but could be better organized for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. However, it lacks information about usage flow (e.g., dependence on kupid_get_schedules) and potential constraints, making it partially complete for a simple detail look-up tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's parameter explanations are critical. It adds value by specifying that schedule_id is the index from kupid_get_schedules results and message_id comes from the same source, providing essential context not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves details of a KUPID academic schedule, with a specific verb and resource. It implicitly differentiates from sibling tool 'kupid_get_schedules' by its need for a schedule_id, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., kupid_get_schedules). It does not mention prerequisites or context, such as that it should be used after obtaining a schedule_id from kupid_get_schedules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states that SSO login is required, which is a prerequisite, but does not mention whether the operation is read-only, any side effects, or data returned beyond 'list of courses'. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with three sentences, front-loading the purpose. However, the second sentence ('It brings the list...') is somewhat redundant with the first. Overall clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description is adequate but lacks details on what fields the returned list contains, any ordering, or pagination. It does not distinguish from similar sibling tools like kupid_my_courses, making it less complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter-specific information, which is acceptable as no parameters exist. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of enrolled courses from Canvas LMS, specifying the source URL. The purpose is clear, but it does not explicitly differentiate from sibling tools like kupid_my_courses or kupid_search_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the need for SSO login but provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The 'kupid' prefix suggests integration with a specific portal, but usage context is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool retrieves a list but does not mention pagination behavior, ordering, or whether it is read-only. The 'page' parameter implies pagination, but no limits or defaults beyond the default value are discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main sentence followed by parameter explanations. It is front-loaded with the purpose. However, it could be more structured (e.g., separate the parameter descriptions into a table or bullet list for easier parsing).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all four parameters with clear meanings and relates board_id to another tool. It also explains keyword is for title search. However, it lacks information on result ordering, maximum results per page, or any filtering options beyond keyword. Given the presence of an output schema, return values are not needed, but behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema: it explains that board_id comes from kupid_lms_list_boards, page defaults to 1, keyword defaults to empty. This compensates for the 0% schema description coverage. However, it could provide more detail on acceptable values or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of posts from a board (게시판의 게시글 목록을 조회합니다). It specifies the resource (board posts) and action (list). Among siblings, 'kupid_lms_get_board_post' retrieves a single post, so this tool is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter descriptions but no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or any prerequisites. For example, it doesn't reference that this is for listing all posts in a board, while 'kupid_lms_get_board_post' is for a single post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the operation is read-only, requires authentication, or any side effects. Only a basic list operation is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief: one sentence stating the purpose in Korean, followed by a clear bulleted list of arguments. Every part is useful, no wasted words, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list schedules with pagination) and the existence of an output schema, the description is sufficient. It covers the basic functionality, though it could mention the output structure or whether results are paged automatically.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its two parameters (0% coverage), but the tool description explicitly explains both parameters: page (page number, default 1) and count (items per page, default 20). This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a list of academic schedules from the KUPID portal. The presence of a sibling tool, kupid_get_schedule_detail, indicates this tool is for listing while the sibling handles details, distinguishing their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It only states what it does, without explaining the context or conditions for using it, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool automatically resolves course_code to course_id using the course list, which is a helpful behavioral trait. However, with no annotations provided, it does not mention error handling, authentication requirements, rate limits, or any side effects beyond a pure read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an 'Args' section, though it includes both Korean and English which may be slightly redundant. It uses bullet-like formatting for parameters, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description adequately covers the tool's functionality. It could be improved by addressing the similarity to 'kupid_get_syllabus' or clarifying the priority when both parameters are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: it explains that course_code is a course code like 'BDC115', that course_id comes from 'kupid_lms_courses', and that either parameter can be used. This compensates for the 0% schema description coverage well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the syllabus for a course, using the verb '조회합니다' (retrieve). However, there is a sibling 'kupid_get_syllabus' with a similar purpose, and the description does not differentiate itself from that tool, which could confuse an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage instructions for the two parameters (course_code and course_id) and explains how they relate, but it does not specify when to use this tool over alternatives like 'kupid_get_syllabus' or if there are any prerequisites (e.g., needing to call 'kupid_lms_courses' first to get course_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the special behavior of returning college list when college is empty and mentions SSO requirement. However, it does not state whether the tool is read-only, describe any side effects, or address 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose line, a scope line, a special behavior note, and a parameter table. It is not overly verbose, though the parameter explanations could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, special behavior, and auth requirement. Output schema exists, so return values need not be explained. However, it lacks details on error handling, pagination, or performance characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's Args section provides detailed semantics for all 6 parameters, including defaults, examples for college and department codes, and enum values for semester and campus. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for offered courses and returns a college list when college code is empty. It distinguishes itself from sibling tools like kupid_my_courses (user-specific) and kupid_get_syllabus (specific course). However, it does not explicitly differentiate from similar search tools like kupid_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes SSO login is required and explains the special case of empty college code. However, it provides no guidance on when to use this tool versus alternatives (e.g., kupid_my_courses, kupid_get_syllabus), nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling, or permissions. It only explains the parameters, leaving the agent without important 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a one-sentence purpose and a parameter list. It is front-loaded with the verb. Slight improvement could be made with clearer separation, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description need not explain return values. However, with no annotations and low behavioral transparency, the description is incomplete. It adequately covers parameter semantics but lacks broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining that scholarship_id and message_id come from the output of kupid_get_scholarships. This adds essential meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('조회합니다' - retrieves) and the resource ('KUPID 장학공지의 상세 내용' - scholarship notice detail). It references sibling tool kupid_get_scholarships for parameter context, but does not explicitly differentiate from other detail tools like kupid_get_notice_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by linking parameters to the output of kupid_get_scholarships. It provides clear context but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It uses '조회' implying a read operation, but does not explicitly state it's read-only, nor mention side effects, permissions, or error handling. More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus parameter details. Every sentence serves a purpose: stating the tool's function, describing what it retrieves, and providing usage guidance. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers purpose, prerequisite, and parameter meaning. It doesn't describe return values, but the output schema fills that gap. It is complete enough 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, course_id, is explained in the description as '과목 ID (kupid_lms_courses의 id 필드)', adding meaning beyond the schema's type and requirement. Schema coverage is 0%, so the description compensates well by linking to another tool's output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Canvas LMS modules (강의자료/모듈), specifying it includes weekly modules and materials. The verb '조회' (retrieve) and resource 'modules' are specific. It distinguishes from sibling tools like kupid_lms_assignments, though it could explicitly mention it returns a list of modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to first obtain course_id via kupid_lms_courses, providing a clear prerequisite and usage context. It does not explicitly state when not to use this tool, but the prerequisite is sufficient for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'retrieve' (read operation). It does not disclose authentication requirements, data scope, pagination, or result ordering. Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and a clarifying detail. No extraneous words; efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description is moderately complete. It gives the purpose and typical content but lacks details on authentication, current user scope, or output format. Could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds context about the returned data (deadline items) but no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the Canvas LMS todo list, specifying it shows assignments and quizzes with approaching deadlines. This distinguishes it from sibling tools like kupid_lms_assignments and kupid_lms_quizzes which likely list all items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deadline-related items but does not explicitly state when to use this tool over siblings like kupid_lms_assignments or kupid_lms_dashboard. No exclusion criteria or alternative hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior beyond what's obvious. It states scraping (read-only) and no authentication needed. However, it does not mention rate limits, error handling, or what happens if a site is unavailable. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear purpose statement, then behavior, configuration, and parameter list. It includes an example. Slightly lengthy but essential content is present. Could trim some repetition but overall good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool involves scraping, dynamic site list, and environment configuration, the description covers key aspects. Output schema exists so return format is likely documented elsewhere. Could mention what the returned list contains (e.g., titles, dates), but still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains each parameter: site_name (empty -> site list), page (default 1), count (default 20). It also describes the environment variable format. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries department/graduate school homepage notices and scrapes the notice board. It distinguishes from the sibling tool kupid_dept_notice_detail by focusing on listing notices rather than details. Mentions returning site list when site_name is empty, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes no authentication required and explains behavior when site_name is empty. It also describes environment variable configuration. However, it does not explicitly state when to use this tool over other notice-fetching siblings like kupid_get_notices, lacking direct alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses an authentication requirement (SSO login) and the data source (portal widget), implying a read operation. However, it does not mention potential rate limits, caching behavior, or whether it modifies any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences for purpose and two bullet points for parameters. It front-loads the core action and then provides details, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (optional parameters, output schema exists), the description adequately covers the authentication requirement, parameter options, and data source. It could optionally mention default behavior of day or whether ics_export is file content or URL, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining the day parameter values ('all', 'mon', etc.) and the effect of ics_export (returns ICS file content if True). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '개인 수업시간표를 조회합니다' (retrieve personal class timetable), which is specific verb+resource. However, it does not explicitly differentiate from the many sibling tools, though it's distinguishable by the 'timetable' resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions SSO login is required and that it parses data from the portal main page timetable widget, but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only query (조회) but does not explicitly state that no data is modified, nor does it mention authentication needs or performance constraints. The description is adequate but lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a front-loaded main sentence in Korean followed by a clarification and a prerequisite note. Every sentence adds value, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description appropriately does not detail return values but mentions what it checks (submission, score, grading status). The prerequisite and parameter explanation are sufficient for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for course_id (0% coverage), but the description compensates by explaining that course_id is the id field from kupid_lms_courses. This adds meaningful context beyond the schema title, though no constraints like range are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool inspects Canvas LMS assignment submission status, including submission presence, scores, and grading status. It identifies the specific resource (submissions) and action (조회/inspect), but does not explicitly differentiate from sibling tools like kupid_lms_grades that may also show scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: first check course_id using kupid_lms_courses. However, it does not specify when to use this tool versus alternatives or when not to use it, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that SSO login is required, which is a behavioral constraint. However, it does not discuss error handling, side effects, rate limits, or what happens if no courses are found. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The Args section is clear and well-structured. A minor improvement would be integrating the Args into a more natural paragraph, but overall it is efficient with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown, but indicated), the description appropriately focuses on parameters and usage context. It covers login requirement, parameter details, and returned fields. Missing elements include no result handling or edge cases, but for a simple retrieval tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds significant value. It explains that year defaults to the current semester and semester accepts specific values ('1', '2', 'summer', 'winter'). This goes well beyond the schema which only has string type with empty defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the user's course registration details, specifies that SSO login is required, and lists the returned information (course number, time, classroom, professor, credits, etc.). This distinguishes it from sibling tools like kupid_search_courses (which searches courses) or kupid_get_timetable (which shows schedule).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (SSO login) and default values for parameters, but does not explicitly compare to sibling tools or state when to use this tool vs alternatives. The context is clear but lacks exclusions or explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose that the tool is read-only, nor does it mention any authentication or side effects. While the name implies retrieval, explicit behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single Korean sentence stating purpose, then an args list. It is front-loaded with the core purpose, and every sentence is useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required param) and presence of an output schema, the description is mostly complete. It explains parameter sourcing and tool purpose. However, it lacks guidance on when to choose this over department-specific alternatives and omits error handling or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description compensates by explaining the provenance of each parameter (from 'kupid_get_notices' results). This adds significant meaning beyond the type/name in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves details of KUPID announcements, distinguishing it from 'kupid_get_notices' (listing) and 'kupid_dept_notice_detail' (department-specific). The verb '조회하다' (retrieve) and resource '상세 내용' (details) are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that notice_id and message_id come from 'kupid_get_notices', providing clear context for use. However, it does not explicitly state when to use this versus sibling tools like 'kupid_dept_notice_detail', nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions SSO login dependency but does not disclose other behaviors like idempotency, error responses, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise—single sentence for purpose followed by clear parameter list. No redundant information. Front-loaded with the key action and authentication requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context for a simple fetch tool: input parameters explained, authentication noted, and output schema exists (handling return values). Could mention that course_code is required, but that's in schema. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage; the description manually defines each parameter with examples and values (e.g., semester options). This adds significant meaning beyond the raw schema, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific verb (retrieve) and resource (syllabus), and includes authentication requirement (SSO login). It effectively distinguishes this tool from siblings like kupid_lms_syllabus by implying it is a different system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions SSO login requirement, which hints at prerequisite, but does not explicitly state when to use this tool over alternatives (e.g., kupid_lms_syllabus) or provide scenarios. Usage context is implied but not fully clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that attachments have time-limited URLs and explains how to download files via file_id. It covers the main behaviors beyond the schema, though no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with paragraphs and clear Args list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 required params and an output schema. The description covers the result contents and file download process sufficiently. Could mention that the tool is read-only for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter in Args, but only provides minimal context (e.g., post_id is from list endpoint). Schema coverage is 0%, so the description does not add much beyond naming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves post details, attachments, and comments, distinguishing it from sibling tools like kupid_lms_list_board_posts which lists posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given, but it's implied from the context that this tool is for getting a single post's full details. Lacks guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it logs in, checks session, and reuses cached sessions. However, it does not detail behavior on invalid credentials, error handling, or whether the tool is idempotent. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The purpose is stated first, followed by requirements and behavior. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and an output schema exists, the description is mostly complete. It could mention what the output provides (e.g., session token), but this is covered by the output schema. Sibling context makes it clear this is a prerequisite tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is complete (100%). The description does not need to add parameter semantics, and it does not. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: logging in to KUPID portal and checking session. It uses a specific verb ('로그인하고') and resource ('KUPID 포털'), and effectively distinguishes itself from sibling tools, which are all specific data retrieval or action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisite environment variables and session caching, but does not explicitly state when to use this tool versus its siblings. It is implied that it should be called before other kupid tools, but this guidance is not direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It explains what data is returned (course cards and assignment/event status) but does not mention side effects, authentication needs, or data freshness. This is acceptable for a simple read-only dashboard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly stating the purpose and content. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a straightforward purpose, the description is complete. The output schema exists to explain return values, so the description does not need to elaborate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description naturally does not need to add parameter meaning. The context signals indicate 100% schema description coverage, and the description provides all necessary context for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it views the Canvas LMS dashboard and specifies the content: course cards and assignment/event status. This distinguishes it from sibling tools that focus on specific elements like announcements or assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining an overview of current courses and tasks, but it does not explicitly state when to use this tool versus alternatives like kupid_lms_courses or kupid_lms_assignments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It describes a read-only operation (list) without disclosing side effects, authentication needs, or return format. While the output schema exists, the description lacks explicit behavioral notes such as 'read-only' or 'no destructive actions'. The score is 3 because it minimally conveys the operation but misses additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short paragraphs. The first defines purpose and lists examples; the second provides usage guidance and parameter documentation. Every sentence earns its place, though the second paragraph could be integrated more smoothly. No unnecessary wording, so score 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is nearly complete. It explains the resource, usage context, and parameter. It does not mention pagination or whether all boards are returned, but the output schema likely covers return structure. Slightly lacking in edge-case behavior, so 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by documenting the only parameter: 'course_id: 과목 ID (kupid_lms_courses의 id 필드)'. This adds meaning beyond the schema (integer) by linking to another tool's field. The description fully covers what the parameter represents and its source, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists boards in a Canvas course, with specific examples like 'Q&A 게시판, 강의자료실'. It distinguishes from sibling tools like kupid_lms_modules and kupid_lms_get_board_post by specifying its purpose of returning board lists, which is a unique resource among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Canvas 네이티브 모듈(kupid_lms_modules)에 자료가 없으면 여기서 찾아보세요.' This tells the agent when to use this tool as an alternative to modules. No exclusion criteria are given, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description effectively discloses behavioral traits: requires SSO login, takes 30-60 seconds due to parallel calls, and recommends caching. Limitations about only covering regular classes are also stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose and organized sections (usage context, limitations, parameters). Slight verbosity in parameter list could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers input parameters, usage context, performance characteristics, limitations, and caching advice. Output schema exists, so return values need not be explained. Complete for a complex query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but the description's Args block adds detailed semantics for each parameter, including partial matching, defaults, and examples, fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries regular class schedules for buildings/rooms, integrated for undergrad and graduate. While sibling tools exist, none are directly comparable for room schedules, so no explicit differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for checking room availability and mentions performance and caching, but does not explicitly state when not to use or list alternative tools for non-regular schedules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions authentication is not needed, which is helpful. However, it does not explicitly state that the tool is read-only or idempotent, nor does it disclose any other behavioral aspects like rate limits or side effects. Given the simple read operation, this is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief purpose statement followed by a note about usage and a clear Args section. It front-loads the purpose and is free of unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detail retrieval tool with an output schema, the description is sufficient. It explains the relationship with kupid_dept_notices and the parameters. It could mention that the output contains detailed content, but since an output schema exists, this omission is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clearly explains that site_name is the key from kupid_dept_notices and article_no is the field from its results. This adds meaningful context beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed content of department/graduate school notices, with the verb '조회' (retrieve). It distinguishes from siblings like kupid_get_notice_detail by specifying the scope (학과/대학원) and the prerequisite use of kupid_dept_notices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to first use kupid_dept_notices and provides the parameters from that tool. It also notes authentication is not needed. While it doesn't explicitly state when not to use, the context is clear for a detail retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read operation ('조회합니다' means inquiry) but does not explicitly state it is non-destructive or mention other behaviors like pagination, rate limits, or authentication requirements. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no fluff. It front-loads the main purpose in a single sentence, followed by a brief body and clearly formatted parameter descriptions. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (return values are covered), the description provides sufficient context for an agent: purpose, prerequisite, parameter semantics, and default behavior. It lacks details on error handling or ordering, but these are minor for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful explanations for both parameters: course_id is the ID from kupid_lms_courses, and upcoming_only filters with a default value. This goes beyond the schema's bare titles and types, providing clear guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves Canvas LMS assignments for a specific course, using specific verbs and distinguishing from sibling tools like kupid_lms_quizzes and kupid_lms_grades. It also explains default behavior (returns all assignments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly instructs users to first check course_id using kupid_lms_courses (a prerequisite) and explains the effect of the upcoming_only parameter. However, it does not mention when not to use this tool versus alternatives like kupid_lms_submissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read-only lookup ('조회') but does not disclose details about side effects, permissions, rate limits, or output format. The presence of an output schema mitigates some need, but the description could add more 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise without any wasted words, presented in both Korean and English with clear structure. Essential information is front-loaded, and every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input and the existence of an output schema, the description adequately covers purpose, prerequisite, and outputs. It does not discuss error handling or edge cases, but for a lookup tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the course_id parameter meaning and directs to kupid_lms_courses.id for obtaining it, adding significant value beyond the schema's minimal 'Course Id' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves grades/scores from Canvas LMS for a specific course, listing specific outputs (current score, final score, grade). It references the prerequisite tool kupid_lms_courses, distinguishing it from siblings like kupid_get_all_grades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to first check the course_id using kupid_lms_courses, providing clear context for when to use this tool. However, it does not mention when not to use it or alternative tools such as kupid_get_all_grades.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('조회') but does not explicitly state read-only behavior, auth requirements, or rate limits. It adds basic behavioral context (listing quizzes) but lacks detail on side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It front-loads the purpose, follows with the prerequisite, and then defines the parameter. At only three short sentences, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, output schema exists), the description adequately covers what the tool does and how to use it. However, it does not mention pagination, sorting, or behavior when no quizzes exist, but the output schema likely fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates. It explains that 'course_id' is the ID from 'kupid_lms_courses', adding meaningful context beyond the schema's basic type. However, it could mention other possible parameters (none) or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists quizzes, exams, and surveys with due dates and time limits for a course. It uses specific verbs ('조회합니다' meaning retrieves) and resource ('퀴즈/시험 목록'). Although not explicitly distinguishing from siblings, the context of sibling tools (assignments, grades, etc.) makes its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to first obtain the course_id from 'kupid_lms_courses', providing a clear prerequisite. It does not specify when not to use the tool or alternatives, but for a simple list tool, this guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that search matches based on title containing the keyword, and specifies default count and board options. However, it does not detail case sensitivity, partial matching, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences and a bulleted parameter list. It is front-loaded with the core purpose and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three simple parameters and an output schema, so the description does not need to explain return values. It covers the search scope and parameter defaults well, but lacks information on error handling or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to keyword (검색할 키워드), board (검색 대상 with options), and count (최대 결과 수, 기본값: 20). While it explains each parameter adequately, the keyword description is somewhat tautological.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches notices, academic schedules, and scholarship notices by keyword in the KUPID portal. It specifies that items with the keyword in the title are returned, and the board parameter distinguishes it from sibling tools that retrieve specific boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (searching across boards by keyword) but does not explicitly mention when not to use it or suggest alternative tools. The sibling tools imply alternatives for non-search retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description covers basic download behavior and parameter roles but omits details like overwrite behavior, permissions, or network requirements. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear goal, a note on file_id source, and a structured Args section. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameters sufficiently. With an output schema present, return value explanation may be unnecessary. Could mention potential errors or prerequisites, but complete enough for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds significant meaning beyond the input schema: explains that file_id comes from modules' content_id, save_dir is an absolute path, and filename defaults to original. Schema only provides types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it downloads a Canvas LMS file to a specified directory. Verb 'download' and resource 'Canvas LMS file' are explicit. Distinguishes from sibling tools that handle other LMS operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use (to download a file) and how to obtain file_id from modules results. Lacks explicit when-not-to-use or alternatives, but guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the authentication requirement and that it fetches finalized grades from a specific screen. It does not mention rate limits or data freshness, but for a read-only operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. It front-loads the purpose, then provides context and parameter details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's function, preconditions (SSO login), and parameter usage. It misses potential details like whether the data is cached or if there are pagination limits, but these are not critical for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section explaining the parameter: 'year_term: 조회할 학년도/학기 코드 (예: "20242R"). 비우면 전체 조회'. This adds semantic meaning beyond the schema, clarifying the format and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all grades, cumulative GPA, and earned credits. It specifies the source ('KUPID 학적/졸업 > 성적사항 > 전체성적조회 화면') and distinguishes from sibling tools by focusing on overall grades versus course-specific grades (e.g., kupid_lms_grades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'SSO 로그인 필요' indicating a prerequisite. It provides an example for the parameter and implies when to use (for overall grades) but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description indicates a safe read operation without authentication. It adds transparency about real-time behavior and lack of auth requirements, though it doesn't mention rate limits or data staleness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus a parameter list. Every part is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a single optional parameter, the description covers the core functionality. It mentions an output schema exists, so return values are assumed documented. Minor gap: no mention of pagination or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the library_name parameter: filter by name, empty for all libraries, and lists possible values. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '조회하다' (query) and the resource '도서관 열람실 좌석 현황' (library reading room seat status). It distinctly differs from sibling tools, which cover LMS, courses, schedules, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that it works without authentication and provides real-time status. While it doesn't list when not to use it, the context is clear and no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format (full HTML without truncation) and the conditional querying behavior based on course_id, providing transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the purpose, then explaining parameter behavior, and ending with an Args section. While efficient, the Args section partly repeats information already stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers essential aspects: return format, filtering behavior, and differentiation from a sibling. The output schema likely handles return structure details, so the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It clearly states course_id is optional, what happens when omitted (all active courses), and references kupid_lms_courses for obtaining course IDs, fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves Canvas LMS announcements (Canvas LMS 공지(announcement)를 조회합니다). It contrasts with kupid_lms_dashboard by noting it returns full HTML without truncation, distinguishing it from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of providing or omitting the course_id parameter (specific course vs. all active courses) and references kupid_lms_courses for finding course IDs. However, it does not explicitly state when to choose this tool over other related siblings beyond the dashboard comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SonAIengine/ku-portal-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server