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_add_business_days

Read-onlyIdempotent

Add or subtract Korean business days to a date, skipping weekends and public holidays, or count business days between two dates for shipping, delivery, and payment deadlines.

Instructions

Add (or subtract) N Korean business days to a date, skipping weekends and public holidays — e.g. '3 business days after today' for shipping ETAs, or count business days between two dates. 영업일 기준으로 날짜를 더하거나 두 날짜 사이 영업일 수를 셉니다. Use for 납기·배송·결제 기한 계산. Needs from (default today) and either days or to.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kr_add_business_days"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoyyyy-MM-dd
daysNo
fromNoyyyy-MM-dd
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
    • addedInput schema / properties / extraHolidays / items / properties / name / maxLength
      Added value: +100
    • addedInput schema / properties / extraHolidays / maxItems
      Added value: +500
    • changedInput schema / properties / from / pattern
      Previous value: -"^\\d{4}-\\d{2}-\\d{2}$"New value: +"^(19|20|21)\\d{2}-\\d{2}-\\d{2}$"
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description correctly spends its words elsewhere: weekend and public-holiday skipping, and that extraHolidays can carry company days off. It omits the ±365 day cap and what happens when optional params are absent, which are the remaining behavioral gaps.

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?

Front-loaded with the core operation and mode behavior, then examples. The Korean sentence largely restates the English one, which is intentional for locale targeting but adds redundancy for a single reader.

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?

Covers the two operating modes and the holiday-skipping model well, which matters for a closed-world calculation tool. However, with no output schema, the description never says what comes back in each mode (a date string vs an integer count), leaving an agent to guess the return shape.

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 75%, and the description adds genuinely useful semantics beyond it: from defaults to today, days may be negative (subtract), and days/to are alternative modes rather than both required. It does not clarify the meaning of the count mode's return versus the date mode.

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 (add/subtract N Korean business days to a date) plus a second mode (count business days between two dates). The explicit 'skipping weekends and public holidays' scoping makes it clearly distinct from siblings like kr_is_business_day and kr_list_holidays.

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?

Gives concrete use cases (shipping ETAs, 납기·배송·결제 기한 계산) and states the input requirement: from defaults to today, and supply either days or to. It does not name the sibling tools to use for a single-day check or holiday listing, so routing is implied rather than explicit.

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