knu-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources: notices, bus arrivals, academic calendar, etc. The main overlap is between get_cafeteria_menu and get_all_cafeteria_menus (single vs. all restaurants), and between get_next_shuttle and get_shuttle_schedule (next departure vs. full timetable), but the descriptions make these differences clear.
Naming Consistency4/5
The naming pattern is predominantly get_<noun>, with one search_notices exception. All names use lower_snake_case and are readable, but the mix of 'get' and 'search' plus the get_ vs get_all_ prefix variation creates minor inconsistency.
Tool Count5/5
Seven tools is well within the ideal 3-15 range for a university information server. Each tool addresses a distinct user need (meals, notices, shuttles, city buses, calendar) without redundancy or bloat.
Completeness4/5
The tool surface covers the main information needs for the university domain: cafeteria, shuttle, bus, notices, and academic calendar. Minor gaps exist, such as no direct route info for shuttles or detailed notice content retrieval, but these are workable limitations rather than critical dead ends.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 43 commits in the last 12 weeks
- No stable releases found
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the safe-read behavior is already covered. The description adds the week offset semantics (0=this week, 1=next week) which is useful behavioral context. However, it doesn't describe what happens if data is unavailable for a given week, or whether partial results per cafeteria are returned.
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?
Single sentence with the essential information front-loaded. The paragraph annotation title adds a redundant but harmless restatement. No wasted words; the week parameter explanation is embedded efficiently.
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?
For a read-only batch query tool with one optional parameter, the description covers purpose, scope, and parameter semantics adequately. However, with no output schema and no description of the return format (is it a combined menu list? per-restaurant structure?), the agent can't anticipate the response shape. Given the tool's simplicity, this is acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter 'week' has no description in the schema. The description does explain week=0/1 mapping in the description body, which compensates partially. However, the parameter semantics are quite thin - only two possible values for a field that's typed as unbounded integer, with no explanation of what happens outside 0/1 range.
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 retrieves cafeteria menus for 3 specific restaurants (백록관/천지관/두리) at Kangwon National University Chuncheon campus. It distinguishes itself from the sibling 'get_cafeteria_menu' (singular) by specifying '일괄 조회' (batch retrieval of all three). The purpose is clear though the scope is campus/location-specific.
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 provides context for when to use it (weekly aggregation of all 3 cafeterias), and the sibling name 'get_cafeteria_menu' implies an alternative for individual menus. However, it doesn't explicitly state when to prefer this tool over get_cafeteria_menu or when to use a single-cafeteria lookup instead. The week parameter usage (0=this week, 1=next week) is explained.
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 include readOnlyHint=true and openWorldHint=true, which signal this is a safe read operation that may return dynamic data. The description adds the '현재 시각 기준' (based on current time) detail and the regular-semester-only operating constraint, which is useful behavioral context. However, it doesn't disclose what happens outside the semester (empty response? error?), nor whether results are sorted or limited to one entry.
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 a single, efficient sentence that conveys purpose and the operating constraint. It's compact and front-loaded with the core function. Slightly more detail on edge cases (off-semester behavior) could improve it, but for a zero-parameter query tool, this level of brevity is appropriate.
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?
For a zero-parameter, read-only tool with readOnlyHint and openWorldHint annotations, the description provides the essential purpose (next departure). The semester-only constraint is captured. However, given the sibling tools include get_bus_arrival and get_shuttle_schedule which could overlap, the description could better clarify what distinguishes 'next departure by current time' from those alternatives. Also, the off-semester behavior is unspecified.
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 tool has 0 parameters, so the description carries no parameter documentation burden. The baseline for 0-param tools is 4. The description accurately reflects that no inputs are needed since it queries based on the current time. No schema coverage concern applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries the next departure time of Kangwon National University's DuRi bus based on the current time ('현재 시각 기준 다음 출발 시각'). It identifies the resource (bus) and the operation (query next departure). However, it doesn't clearly distinguish from sibling tools like get_bus_arrival or get_shuttle_schedule, which could overlap in purpose. The verb '조회' (query) plus resource '두리버스' is reasonably specific, but the relationship to nearby siblings is unclear.
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 mentions '정규학기만 운영' (only operates during regular semesters), which provides some usage context. However, it doesn't explicitly state when to use this vs alternatives like get_bus_arrival or get_shuttle_schedule, nor does it note any exclusions or when NOT to use it. The semester-only constraint is helpful context but no alternatives are named or distinguished.
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 declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds a list of valid stops and the behavior of omitting route, but doesn't describe return format, whether results are ordered by arrival time, or any live-data characteristics (refresh, latency). With readOnlyHint present, the bar is lower and the added stop list provides some context value.
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?
A single sentence with embedded useful parameter details — efficient and front-loaded with the main purpose. The stop list and route-omission note are valuable and compact. No filler 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?
For a read-only query tool with no output schema and no required parameters, the description covers purpose, valid inputs, and key behavioral switches. It doesn't describe the return payload shape, which would be helpful since there's no output schema, but the read-only nature lowers the completeness burden.
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 description coverage is 0%, so the description carries the burden. It explains the stop parameter's valid values (8 named stops) and route's omission behavior, adding substantial meaning beyond the raw schema which only shows defaults. It does not clarify the route parameter's format (e.g., route number vs name), but covers the key semantics.
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 queries real-time city bus arrival info at Kangwon National University stops, naming specific stops. The verb and resource are specific, but it doesn't distinguish from siblings like get_next_shuttle (which handles shuttle buses) — though the resource difference (city bus vs shuttle) is implicit.
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 lists valid stop values and notes that omitting route returns all routes. It does not explicitly state when to use this vs get_next_shuttle or other bus-related tools, nor when not to use it. Context is implied by the stops being city bus stops rather than shuttle stops.
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 provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the valid option ranges for restaurant and week, which is useful behavioral context beyond the annotations. It doesn't mention return format, data freshness, or error behavior, but annotations carry the main burden.
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 a compact single sentence plus a parameter listing. It front-loads the core purpose and packs the essential parameter constraints efficiently. Slightly dense but nothing redundant.
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?
For a menu-query tool with good readOnly+openWorld annotations and no output schema, the description covers the essential selection domain (restaurant+week options). Some gaps remain: no mention of what the response contains (e.g., daily menu details), whether meals are filtered by time, or how availability is indicated. Considering the tool's moderate complexity and zero schema coverage, it's adequate but not rich.
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 0%, so the description must compensate by documenting parameters. It does list the valid values for restaurant (백록관/천지관/두리) and week (0=이번주, 1=다음주), giving real semantic meaning beyond the bare schema fields. Both parameters have defaults, and the description adds the valid-domain detail that fills the coverage gap.
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 verb+resource: '강원대 춘천캠퍼스 학식 식단을 조회합니다' (queries cafeteria menu). It explicitly names the two selectable parameters (restaurant: 백록관/천지관/두리, week: 0=이번주/1=다음주), which distinguishes it well from siblings like get_all_cafeteria_menus and get_next_shuttle.
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 gives implicit usage context by enumerating valid restaurant and week options, orienting the agent on what to pass. However, it does not explicitly state when to choose this tool vs get_all_cafeteria_menus (which likely fetches all cafeterias), nor does it provide exclusions or alternative 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?
Annotations already declare readOnlyHint=true, so the description's read-only nature is pre-covered. The description adds the semester-only operational constraint, which is valuable behavioral context beyond structured data. It doesn't contradict annotations. Given the annotations carry the safety burden, a middle score is appropriate as the description adds modest extra 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that states purpose and a key constraint efficiently. It's appropriately sized for a zero-parameter read-only tool and front-loads the key identifying information (the university and campus). No wasted words.
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 zero-parameter read-only tool with readOnlyHint and openWorldHint annotations, the description is reasonably complete. It identifies the system (강원대학교 도우미), the resource (순환버스/두리버스 시간표), the campus (춘천캠퍼스), and the operational constraint (정규학기). The sibling differentiation could be stronger, but the scope is clear. Output schema absence doesn't matter much for a schedule list.
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 tool has 0 parameters, so there's no parameter burden. Baseline is 4 for 0-param tools. The description references the schedule being for the Chuncheon campus specifically, which gives context about what the returned data pertains to, compensating for the absence of filters.
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 tool queries the on-campus shuttle bus (두리버스) timetable for Kangwon National University Chuncheon campus, with a specific verb '조회합니다' (query/view). It's distinct from siblings like get_next_shuttle and get_bus_arrival which focus on real-time arrival rather than the schedule. However, it doesn't explicitly differentiate from those siblings.
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 notes the service operates only during regular semester ('정규학기에만 운영'), which is useful usage context. However, it doesn't explicitly state when to prefer this over siblings like get_next_shuttle or get_bus_arrival, nor does it clarify when NOT to use it. The usage context is implied rather than explicitly guided.
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 provide readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: the source site may not include certain schedules, and the year argument is ignored—information not in annotations. This goes beyond the structured data 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 concise and front-loaded with the core purpose, followed by a useful limitation note and parameter clarification. 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.
Completeness5/5
Given 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 and no output schema, the description covers purpose, limitations, and parameter behavior. Combined with annotations, the agent has everything needed to select and invoke the tool 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?
Schema coverage for parameters is 0%, but the description explicitly explains the sole parameter 'year' as backward-compatible and having no effect on results. This adds meaningful meaning beyond the schema, which only lists type/default.
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 verb and resource: '조회합니다' (queries) the 'current upcoming major academic schedules' of Kangwon University Chuncheon Campus, with examples. It is distinct from all sibling tools (cafeteria, notices, shuttle, bus), so no ambiguity.
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?
Provides clear context: intended for current upcoming schedules and explicitly notes limitations (past/far-future schedules may be absent). However, it does not explicitly mention alternatives or when not to use, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already known. The description adds valuable behavioral context beyond annotations: the search is a title-only filter, it relies on scraping recent pages rather than a native search endpoint, and results are limited by the pages parameter (default ~160 items). This effectively discloses the tool's operational constraints and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-organized single sentence that fronts the purpose, then adds a necessary caveat about the missing keyword search and a concrete adjustment instruction. Every sentence earns its place with 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 filtered-lookup tool with readOnlyHint and openWorldHint annotations, the description is largely complete: it states the source, the filtering mechanism, default scope, and how to broaden the search. It does not describe the return value format or pagination details, but since there is no output schema this is a minor gap rather than a critical one for this relatively simple search tool.
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 description coverage is 0%, so the description must compensate. It explains 'query' semantics (search by title containment) and 'pages' semantics (how many pages to scan; increase for older results). 'limit' is not directly explained, but its meaning is reasonably inferable from context. The description adds meaningful value for the two most important parameters beyond the raw 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 clearly states the tool's purpose: searching for 학사공지 notices whose titles contain the query, with a specific scope (강원대학교). It explicitly describes the mechanism (scraping recent pages and filtering by title) and distinguishes from siblings by specifying the resource ('학사공지') and the search semantics. The verb '검색하다' + resource is specific and clear.
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 provides explicit usage guidance: it explains that the site does not support keyword search, so the tool filters recent pages (default 10 pages, ~160 items) by title, and explicitly tells the agent to increase 'pages' to find older items. This gives concrete when-to-use and how-to-extend instructions that are actionable.
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:

[![knu-mcp MCP server](https://glama.ai/mcp/servers/LEEseungseok-01/knu-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LEEseungseok-01/knu-mcp)

Score Badge

Copy to your README.md:

[![knu-mcp MCP server](https://glama.ai/mcp/servers/LEEseungseok-01/knu-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LEEseungseok-01/knu-mcp)

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/LEEseungseok-01/knu-mcp'

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