jbnu-lms

by moon0825

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0
Disambiguation2/5
Several tools share overlapping purposes: get_recent_changes, get_attention_inbox, get_daily_briefing, and get_weekly_study_plan all summarize deadlines and changes, while get_upcoming_deadlines and get_attention_inbox both list deadlines. connect_lms and open_lms_source also appear to serve similar authentication/browser-launch functions.
Naming Consistency2/5
The naming pattern is inconsistent: most tools use get_*, but list_courses, connect_lms, open_lms_source, disconnect_lms, download_course_material, report_lms_problem, suggest_lms_feature, retry_feedback_delivery, discard_local_feedback, and check_assignment_submission break the pattern. Even within get_*, some pairs like get_announcements/get_announcement_detail are consistent, but the overall mix is not.
Tool Count2/5
With 25 tools, the set is at the high end and feels heavy. While an LMS integration could justify many operations, the presence of multiple near-duplicate summary tools (e.g., get_daily_briefing, get_attention_inbox, get_weekly_study_plan) suggests the count could be trimmed without losing functionality.
Completeness4/5
The tool set covers the core LMS workflows well: authentication, course listings, announcements, assignments, materials, completion tracking, downloads, change summaries, and user feedback. Minor gaps exist (e.g., no direct quiz/submission detail beyond assignment focus), but the surface is largely complete for a read-oriented LMS assistant.
Average 4.3/5 across 25 of 25 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on September 7, 2026
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it explicitly states the tool writes nothing to the calendar and requires a duplicate check using fingerprint and title/time/URL. This goes beyond the readOnlyHint and idempotentHint already provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences covering purpose, side-effect-free behavior, and the required duplicate-check step. Every sentence carries essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and its side effects, but it does not specify the structure or content of the returned calendar candidates. Since there is no output schema, an agent is left to infer the return format, which is a notable gap for a tool that produces a list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (days, course_id, include_overdue) have descriptive schema text covering their meaning and defaults. The tool description does not add further parameter-specific guidance, but the schema coverage is complete, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it normalizes LMS assignments/quizzes into calendar candidates and explicitly notes it writes nothing to the calendar. This distinguishes it from listing tools like get_upcoming_deadlines, though it does not name a specific sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to check for duplicates before use is a practical behavioral guideline, but there is no explicit statement about when to choose this tool over similar deadline-related siblings. The 'writes nothing' note hints at a preview use case but is not framed as a selection criterion.
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 annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context about sorting order and included fields, which supplements the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, directly states the main behavior, and lists key output fields in one sentence. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description enumerates the expected fields (deadline, remaining time, submission status, late allowance, URL). It could mention sorting direction explicitly in the same phrase, but the stated 'deadline order' is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters (course_id and include_submitted), achieving full parameter coverage. The description adds no further parameter-level detail, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows an assignment list sorted by deadline, and lists the included fields. This makes the purpose specific and distinguishable from sibling tools like get_upcoming_deadlines or get_assignment_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to prefer this tool over related siblings, such as get_upcoming_deadlines or check_assignment_submission. There is no mention of alternatives or conditions that would guide selection.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful filter behavior and material-type scope, but does not disclose output shape, ordering, pagination, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose and followed by the key filtering capabilities. No filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema documentation and safety annotations, the description is adequate for correct invocation. It could mention output format or pagination, but these are not critical for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description mentions week and query, which adds little beyond the schema, and does not clarify kinds or course_id further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows course materials by week, enumerating concrete types (files, folders, links, videos, pages). This makes it distinguishable from sibling tools like announcements or assignments, though it does not explicitly name a differentiating sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: retrieve a course's weekly materials, with optional filtering by week and query. There are no explicit exclusions or alternative tool recommendations, but the context is sufficient for an agent to decide when to invoke it.
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?
Beyond annotations, the description discloses the default save location, that the path is reported back, and that target_dir is restricted to subfolders of the default download folder with outside paths rejected. This is useful behavioral context, though it does not mention overwrite behavior or what happens if both cm_id and file_url are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the destination and result first, then the required input condition. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains the outcome (saved locally and path returned). It covers the key input constraint and directory restrictions. It could be slightly more complete by noting how to obtain cm_id or file_url (e.g., via get_course_materials), but this is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the default folder pattern (~/Downloads/jbnu-lms/<course name>/), that cm_id or file_url are alternatives, and that target_dir cannot escape the default folder. This helps the agent understand parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (saving course material files locally), the destination folder, and the result (returning the path). It identifies the resource as course material, but does not explicitly distinguish itself from sibling get_course_materials beyond the download/save focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for saving files to the local Downloads folder and explains that either cm_id or file_url is required. However, it does not explicitly state when to prefer this over sibling tools like get_course_materials, nor does it mention exclusions such as only being useful for local storage needs.
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?
Annotations already declare readOnlyHint and idempotentHint, so no additional safety context is needed. The description usefully specifies the returned fields (ID, name, progress, URL), which helps set expectations for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the main purpose stated first and the optional behavior explained second. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the output fields (ID, name, progress, URL), which is essential given the lack of an output schema. It does not cover potential edge cases like pagination or errors, but for a simple list tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter include_all is fully described in the schema (100% coverage) and also explained in the main description. Its boolean meaning and default behavior are clear, requiring no extra inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists enrolled courses with ID, name, progress, and URL, and explains the include_all option for completed courses. It is distinct from siblings like get_course_overview, but does not explicitly name them as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the include_all parameter but gives no guidance on when to use this tool over sibling tools such as get_course_overview or open_lms_source. Users are left to infer the appropriate context from the tool name.
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?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds genuinely new behavioral context: it performs AI estimation of requirements and submission clues, and it explicitly marks estimated content separately. This goes beyond what annotations provide, though it does not mention estimation reliability or failure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the output categories and adds the AI-estimation caveat with no filler. Every clause contributes a distinct piece of information, and the parenthetical about marking estimates is placed at the end without cluttering the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only detail tool with no output schema, the description enumerates the returned content well: original text, deadlines, submission status, attachments, submitted files, and AI-estimated requirements. The schema covers parameter meanings. It does not specify behavior when both url and cm_id are supplied or when the assignment cannot be found, but those are minor for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully documented in the schema: url has format uri and the expected /mod/assign/view.php?id= shape, and cm_id is described as the module ID from the URL. With 100% schema description coverage, the baseline of 3 applies; the tool description adds no parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('보여 주고' / show) and a precise resource: assignment detail, including original description, deadlines, submission status, attachments, and submitted files. The '상세·요구사항 분석' framing clearly distinguishes this from list-level siblings like get_assignments and from status-only check_assignment_submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, and no sibling alternatives are named. The intended use is implied by the title and by the rich output list, but the description does not tell an agent to prefer this over check_assignment_submission for a quick status check or to call get_assignments first.
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 annotations already provide read-only, idempotent, and non-destructive hints; the description adds no further behavioral context beyond what the annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and directly conveys the tool's purpose with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the key components of the briefing (deadlines, announcements, changes, AI suggestions) sufficiently for a simple aggregation tool; no output schema exists, so no additional return value details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'days' parameter is clearly explained as the lookahead period for deadlines, complementing the schema description and leaving no ambiguity about its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compiled daily briefing covering overdue tasks, today's and weekly deadlines, announcements, and changes since last check—making it distinct from the more specific sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes the intended scenario ('a single answer to tell me what to do today') but does not explicitly contrast when to use this aggregator versus the more granular tools like get_upcoming_deadlines or get_announcements.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral details about default filtering and grouping, which are not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and does not contain redundant or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple read-only tool with four optional parameters, all documented in the schema. It explains the purpose, grouping, and default filter, though it does not elaborate on output format or sorting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameters are already described in the schema. The description does not add parameter-specific detail beyond the existing schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('shows'), a specific resource (deadlines), and a distinguishing grouping (today/tomorrow/this week/overdue), making it distinct from sibling tools like get_assignments or get_announcements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for viewing upcoming deadlines, especially with the default filter excluding submitted items, but it does not explicitly state when to prefer this tool over alternatives such as get_assignments or get_attention_inbox.
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?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful behavior beyond that: non-tracked activities are excluded and not assumed incomplete, only_incomplete defaults to true, and course state is reused without extra requests. Return shape is not described, but annotations carry the safety burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose, use case, default behavior, exclusion rule, and read-only note are all packed efficiently. Information is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with full schema coverage and strong annotations, the description covers purpose, use case, defaults, exclusions, and state reuse. The only gap is the lack of detail about the return value shape, but that is inferable and no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the default behavior of only_incomplete and that false includes completed items, which the schema alone does not convey as clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows completion status for activities with completion tracking enabled in a course, using specific verbs and resource scope. It does not explicitly name or contrast a sibling tool, so it falls just short of full differentiation credit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case: find unwatched online lectures and incomplete activities. It does not state when not to use the tool or name alternatives, but the context is clear enough for an agent to decide.
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?
Annotations already mark the operation read-only, idempotent, and non-destructive, and the description's 'shows' is consistent with those hints. It adds that attachments are part of the output, but it does not disclose behaviors like max_chars truncation effects or URL-versus-field precedence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler: the first states the tool's function, the second gives the input routing. The most important usage constraint is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only detail tool with no required schema parameters, the description covers the identifier alternatives (list-result fields or URL), and the schema covers max_chars. With no output schema, the description states the return scope (body plus attachment list), so the only notable gap is detailed response formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all four parameters, so the baseline is 3. The description adds practical meaning by connecting board_cm_id and bwid to get_announcements results and by offering the URL as an alternative, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb ('보여 줍니다' / shows) and a clear resource: the announcement post body and attachment file list. It distinguishes itself from the sibling get_announcements list tool by framing this as the detail view and naming the identifier inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use board_cm_id and bwid from get_announcements results, or a post URL. This gives clear context for when to invoke the tool, though it does not spell out exclusions versus other detail tools such as get_assignment_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only and non-destructive behavior. The description adds that it does not change the LMS and is not an official receipt, which reinforces the safety profile and sets expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loads the primary purpose. It avoids unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key outputs (statuses, files, deadline risk, evidence) and limitations (not official receipt). Without an output schema, this is sufficient for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, and the description does not add additional parameter semantics beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: re-reading the assignment detail screen to verify submission status, files, and deadline risk. It explicitly notes it does not modify the LMS and is not an official receipt, providing a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a confirmation use case but does not explicitly compare with sibling tools like get_assignment_detail or specify when to prefer this tool. It lacks explicit guidance on when to use it versus 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?
Annotations already declare read-only, idempotent, and non-destructive. The description adds meaningful transparency about auto-finalizing the connection after browser close and making an actual LMS request when verify=true, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences cover what the tool shows, a specific edge-case behavior, and the optional verification mode. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description lists the displayed fields (login status, auth method, last sync, storage method), which is sufficient for a status check. Missing error conditions are not critical for this simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter verify is fully described in the schema with a clear meaning and default value. The description reinforces when verify=true changes behavior, providing complete parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: shows login status, authentication method, last sync time, and storage method, plus optional session verification. The verb 'shows' and 'checks' are specific, and the resource (auth status) is distinct from sibling connection management 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one usage scenario (calling after closing the login browser) and explains the verify parameter, but does not explicitly contrast with sibling tools like connect_lms or disconnect_lms. Guidance is useful but implicit rather than explicit.
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?
Annotations already convey read-only, idempotent, and non-destructive behavior, and the description adds that cm_id values can be passed to other tools, which is useful behavioral context. It does not describe error handling or empty results, but the safety-related aspects are well covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the main content and the reusable cm_id without unnecessary detail. It is well structured and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool returns (weekly module list, notice board location, cm_id) despite lacking an output schema. It is sufficient for basic usage, though more detail about the response format might be helpful given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter course_id is described as 'list_courses 의 강좌 ID', directly telling the user where to obtain the value. Schema coverage is 100% and the description adds practical source guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows the module list by week and the notice board location, using the specific verb '보여 줍니다' (shows). It also explains that cm_id values can be reused by other tools, which distinguishes its purpose from related tools like get_course_materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the course structure and cm_id values, but it does not explicitly state when to choose this tool over siblings such as get_course_materials or get_assignments. The mention of cm_id reuse gives some guidance, but explicit alternative comparisons are absent.
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?
Annotations already declare read-only and non-destructive behavior. The description adds meaningful detail by stating the response will not re-expose the report body, reinforcing the read-only nature and clarifying output privacy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the tool's primary purpose and scope. It avoids unnecessary detail and clearly communicates what is included and excluded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete enough. It specifies that returns are receipt numbers and transmission status, and explicitly states that the feedback body is not included, covering key expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the baseline is 4. The description does not need to add parameter-specific meaning because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows only receipt numbers and transmission status for feedback submitted on this PC. It distinguishes the tool from related feedback actions by explicitly limiting its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking local feedback status but does not explicitly name when to use it versus sibling tools like retry_feedback_delivery or discard_local_feedback. It provides some boundary by noting it only shows receipt numbers and status, but lacks direct usage guidance.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds details about the content (AI suggestions, overdue items) but does not introduce any behavioral caveats, which is consistent with the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the core function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does and what it includes (deadlines, AI suggestions, next week preview, overdue). No output schema exists, so no return format needs explanation; the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description does not need to add parameter information, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: organizing this week's daily deadlines and AI suggestions, plus next week's preview and overdue items. It distinguishes from siblings like get_upcoming_deadlines and get_daily_briefing by focusing on a weekly plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (this week's plan) but does not explicitly contrast with alternative tools. However, the clear scope of 'weekly' vs. 'upcoming' or 'daily' makes usage inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral details beyond the annotations: it sends submitted content to a remote address if configured, requires explicit user consent before calling, avoids collecting personal and LMS academic content, and stores locally in a retry-pending state on failure. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two focused sentences that convey purpose, consent requirement, privacy scope, and failure behavior without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and the absence of an output schema, the description is complete enough for an agent to understand when and how to invoke the tool, what side effects may occur, and what safeguards are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON schema already provides 100% coverage of all 8 parameters with clear descriptions and constraints. The tool description adds overall context about privacy and consent but does not significantly enrich per-parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: receiving new feature or UX improvement suggestions. It uses a specific verb ('접수합니다') and a specific resource ('새 기능이나 UX 개선 의견'), which distinguishes it from problem-reporting siblings like report_lms_problem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for feature/UX suggestions) and includes important procedural guidance about showing content and obtaining explicit consent. However, it does not explicitly contrast this tool with alternatives such as report_lms_problem or explain 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent, so the safety profile is covered. The description adds meaningful behavioral context: the external board source, latest-first ordering, marker meanings (📌/🆕/📎), and the 'since last check' semantics of only_new. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the core function, then efficiently pack marker semantics and the only_new flag behavior. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only list tool with all parameters documented in the schema, the description is largely complete and even interprets output markers. It does not describe the exact return shape, but the marker legend and clear scope make the tool callable without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning for only_new by explaining it as announcements posted since the last check, which is richer than the schema's '새 글만'. Other parameters are adequately covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('보여 줍니다'), identifies the resource (강좌 공지사항 / 전북대 ubboard), states the ordering (최신순), and clearly implies this is the list counterpart to get_announcement_detail. An agent can distinguish it from siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for listing announcements and explains the only_new filtering condition. However, it never names alternatives or states when not to use this tool, leaving routing to inference among many siblings like get_attention_inbox and get_daily_briefing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses side effects: it updates only the local comparison baseline and does not modify the LMS. This aligns with the annotations and gives the agent an accurate model of state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the core value, and includes the most important behavior (top 3 actions and local-only update) without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough context for successful use: what data is aggregated, what is prioritized, and what state changes occur. It does not specify the output shape, but no output schema is provided and it is not required for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are documented with reasonable descriptions in the schema, so schema coverage is complete. The description itself does not add additional parameter-level detail, which is acceptable because the schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it aggregates deadlines, announcements, assignment changes, new materials, and LMS change logs into a single student attention inbox, and prioritizes the top 3 actions. This is specific and effectively distinguishes it from sibling tools like get_announcements or get_upcoming_deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The title and description convey clear usage context: use this when a student needs a consolidated, prioritized view of things not to miss. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough for an agent to choose it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important side effects: it sends data immediately if a remote collection address is configured, stores locally for retry on failure, and explicitly excludes sensitive LMS login info, student IDs, course names, and notice/assignment content. It also requires explicit user approval before sending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it states the purpose, then the consent requirement, then privacy exclusions, then transmission/retry behavior. Every sentence adds meaningful information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, consent, privacy, and retry behavior, which is adequate for this tool. Minor ambiguity remains about what happens when no remote collection address is configured, but this is not critical given the schema and overall clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% parameter description coverage with detailed field descriptions. The tool description adds general behavioral context about consent and privacy but does not materially clarify individual parameters beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '이 MCP의 오류나 잘못된 결과를 접수합니다' (accepts reports of errors or incorrect results from this MCP). This distinguishes it from sibling tools like suggestion or feedback tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: use for errors or incorrect results, and mandates showing a summary, details, diagnostic ID, and technical info and obtaining explicit consent before calling. It does not explicitly mention alternatives or when not to use it, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructive and idempotent behavior, and the description adds specific destructive scope: cookies/tokens, the optional browser profile for original-text viewing, and the optional local snapshot for change detection. This is meaningful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the main action front-loaded and conditional behaviors described efficiently. There is no filler or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with two optional booleans and no output schema, the description covers the deletion scope and flag behavior completely. It does not need to explain return values, and the annotations already cover safety semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both booleans with 100% coverage, so the baseline is 3. The description adds value by explaining the real-world effect of each flag, which helps the agent decide whether to set delete_browser_profile or delete_snapshot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Deletes saved LMS session (cookies/tokens).' It also differentiates itself from sibling tools like connect_lms and get_auth_status by making clear it is the teardown operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the main action, and the flag conditions are explained. However, it does not explicitly contrast this tool with connect_lms or get_auth_status, nor does it state when not to use it or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond the annotations: it opens a dedicated browser, does not automate, avoids putting cookies/tokens in URLs or command lines, and requires the user to authenticate on the official login screen. It also notes restrictions on allowed URLs/parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by usage trigger and security constraints. Each sentence adds relevant information with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool, the description covers what it does, when to use it, and important security behavior. It does not describe return values or failure modes, but no output schema is present and those details are less critical for this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The URL parameter is explained as the LMS original URL returned by list/detail tools, which adds useful context beyond the URI format. It could be slightly more explicit about requiring a full valid URL, but the current description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: opening the original LMS page in a dedicated Chrome/Edge browser without automation. It distinguishes this from sibling tools by emphasizing the external browser and non-automated nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly gives a trigger condition: use when a chat link opens in an internal browser that is not logged in. It does not explicitly name an alternative sibling tool, but the condition is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool discloses significant side effects: it opens a non-automated browser, saves the LMS session via DPAPI, preserves a dedicated Chrome profile with only LMS cookies, and terminates the dedicated Chrome after detecting the LMS home. It also warns the user not to close the window directly, which is consistent with the openWorldHint and idempotentHint 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and mostly efficient, but some phrasing is repetitive and awkward, such as '원문 보기용 프로필로 정리합니다' and the repeated warnings about not closing the window and not passing credentials. Still, every sentence contributes necessary operational or safety information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow, side effects, user actions, and the follow-up step via get_auth_status when wait_seconds is 0. It does not explicitly state the tool's return value or output, but since no output schema is provided and the expected follow-up is clear, the behavior is sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter wait_seconds is fully described in the schema, including its default value of 120, the allowed range, and the special meaning of 0 (open and return immediately). The description adds useful behavioral context about waiting for LMS detection and session saving.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool opens a normal browser at LMS /my/ for user-initiated login, and it distinguishes this from sibling tools like open_lms_source and get_auth_status by describing manual authentication and session preservation. The action, resource, and intended login workflow are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage instructions: the user must perform integrated login via the third 'ID login' tab and select a passkey for second-factor authentication. It also warns not to pass credentials and explains the wait_seconds=0 case, directing the agent to call get_auth_status afterward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although the annotations already indicate destructive=true and readOnly=false, the description adds crucial behavioral context: it deletes only the local copy, not the remote one, and requires explicit user confirmation. This goes beyond the annotations and informs the agent of the exact side effects and prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no redundant words or unstructured extras. It conveys the core action, the scope, and the confirmation requirement in two clear sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for an agent to decide when to call the tool: it knows what will be deleted, what will not, and the mandatory confirmation step. No output schema is needed for a delete operation, and the given information is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well described. report_id is clearly tied to get_feedback_status receipts, and confirm_discard is explained as requiring explicit user confirmation. These descriptions add meaning beyond just the parameter types and patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a local feedback copy identified by a receipt number, explicitly distinguishing it from remote copies. The verb 'delete' is specific and the resource is well-defined, making it distinct from sibling tools like retry_feedback_delivery or get_feedback_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that only the local copy is deleted and that remote copies are not affected, and it mandates that the user must be informed and explicitly confirm before execution. This provides clear guidance on when and how to use the tool, though it does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently explains the snapshot mechanism, including that the first run only creates a baseline and that 'update_snapshot' controls whether the snapshot is refreshed. This complements the readOnlyHint=false annotation and gives the agent a clear picture of state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the main purpose first and then explaining the snapshot behavior and optional parameter. No redundant or vague language is used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides sufficient context for an agent to decide when and how to invoke the tool. It covers the scope of changes, snapshot mechanics, and the key 'since' parameter, making it complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the schema, and the description adds meaningful context: 'since' is the baseline time (defaulting to snapshot), 'course_id' filters to a specific course, and 'update_snapshot' controls snapshot refresh. The coverage is complete and the semantics are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows new announcements, new assignments, assignments with changed deadlines/submission status, and new course materials since the last check. It also explains the snapshot behavior and the optional 'since' parameter, distinguishing it from single-entity retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (after a previous check, first run creates a snapshot, 'since' can override the baseline). However, it does not explicitly name alternative tools or state when not to use it, so it falls slightly short of explicit alternative guidance.
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 goes beyond the annotations by specifying that no new content is created and already sent reports are not duplicated. It does not mention whether the local queue is cleared after sending, but the main side effects are reasonably transparent given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the action immediately and then adding relevant clarifications in a compact second sentence. No unnecessary detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains what the tool does, when it is applicable, and the parameter's meaning. Although there is no output schema, the action-oriented nature of the tool makes the description sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'limit' has a clear description stating the maximum number of items to retry and its default value of 20. This fully covers the parameter's meaning beyond the basic schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resends locally queued feedback (problem reports/feature suggestions) caused by server failures, and explicitly distinguishes it from creating new content or duplicating already sent reports. This makes the core purpose unambiguous and differentiates it from related feedback tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool: when there is locally queued feedback due to collection server failure. It also clarifies what it does not do (no new content, no duplicates), which helps rule out alternative tools like report_lms_problem or get_feedback_status.
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

jbnu-lms MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![jbnu-lms MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/moon0825/jbnu-lms-student/badges/card.svg)](https://glama.ai/mcp/servers/moon0825/jbnu-lms-student)

Score Badge

Copy to your README.md:

[![jbnu-lms MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/moon0825/jbnu-lms-student/badges/score.svg)](https://glama.ai/mcp/servers/moon0825/jbnu-lms-student)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/moon0825/jbnu-lms-student'

If you have feedback or need assistance with the MCP directory API, please join our Discord server