Skip to main content
Glama
Sign In
K-MCP (Korean toolkit for AI agents)

K-MCP (Korean toolkit for AI agents)

by groove79
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kr_list_holidays

Read-onlyIdempotent

Lists Korean public holidays for a specified year, including substitute holidays and election days, so agents can plan schedules, delivery promises, and payroll calendars.

Instructions

List Korean public holidays for a year including computed 대체공휴일 (substitute holidays) and election days. Offline; lunar dates tabled for 2025–2028. 연도별 공휴일(대체공휴일 포함)을 반환합니다. Use for scheduling, delivery promises, payroll calendars. Needs year.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>"
    },
    "name": "kr_list_holidays"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
extraHolidaysNoAdditional holidays (e.g. from kr_holidays of the public-data server, or company days off)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • changedInput schema / properties / extraHolidays / items / properties / date / pattern
      Previous value: -"^\\d{4}-\\d{2}-\\d{2}$"New value: +"^(19|20|21)\\d{2}-\\d{2}-\\d{2}$"
    • addedInput schema / properties / extraHolidays / items / properties / name / maxLength
      Added value: +100
    • addedInput schema / properties / extraHolidays / maxItems
      Added value: +500
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the description correctly spends its words on things annotations cannot express: it runs offline, substitute holidays are computed, and lunar dates are only tabled for 2025–2028. That data-coverage caveat is the single most important behavioral fact for an agent and it is disclosed. It loses a point for not saying what happens for years outside 2025–2028 (error, approximation, or solar-only output), which is exactly where the tabled-range warning matters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The English opening is well front-loaded and information-dense, but the Korean sentence is a near-verbatim duplicate that adds no new facts for an agent, and the trailing 'Needs year' repeats what the required array already encodes. Roughly a third of the text is 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?

With only two parameters and full annotation coverage, the definition is close to sufficient, and the 2025–2028 caveat plus use-case framing covers the main decision points. Because there is no output schema, the description should at least sketch the shape of a returned holiday entry (date, localized name, type flags) and the out-of-range behavior; both are missing.

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 coverage is 50% and the description only says 'Needs year', which merely restates the required field and adds no semantics beyond the schema's min/max bounds. The genuinely ambiguous parameter, extraHolidays, is never mentioned in the description at all — an agent cannot tell from the description whether injected holidays are merged into the list, deduplicated, or whether they influence substitute-holiday computation.

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?

States a specific verb and resource ('List Korean public holidays for a year') and names the non-obvious inclusions (computed 대체공휴일 and election days) that separate its output from a plain holiday table. An agent can tell this apart from kr_is_business_day (a per-date check) and kr_add_business_days (date arithmetic) without opening any schema.

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?

'Use for scheduling, delivery promises, payroll calendars' gives clear positive usage contexts. It stops short of naming alternatives or when-not cases (e.g. 'for a single-date business-day check use kr_is_business_day'), so it sits at clear-context-without-exclusions.

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

Deploy Server

Other Tools