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_is_business_day

Read-onlyIdempotent

Check whether a date is a Korean business day and get the next and previous business days before promising delivery or meeting dates.

Instructions

Tell whether a date is a Korean business day (평일, not a public holiday), and give the next and previous business days. 해당 날짜가 영업일인지 확인합니다. Use before promising a delivery/meeting date. Needs a date (default today, KST).

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_is_business_day"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoyyyy-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
    • changedInput schema / 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

A4.3/5.0
Behavior4/5

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

Annotations already establish that this is a safe, read-only, idempotent operation, so the description only needs to add context beyond that. It meaningfully adds the default date behavior and KST timezone, clarifies that a business day excludes public holidays, and states that next and previous business days 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?

The definition is short and front-loads the core purpose, with usage guidance and the default-date note following naturally. The Korean sentence repeats the English purpose rather than adding new information, which is the main minor 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 read-only predicate tool with complete schema coverage and no output schema, the description covers the essential purpose, usage, and default date behavior. It does not describe the exact return structure, but it does say what the tool conceptually returns.

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 parameter documentation is already strong. The description still adds value by noting that the date defaults to today in KST, though it does not mention the extraHolidays parameter that the schema documents.

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: telling whether a date is a Korean business day, defined as a weekday that is not a public holiday. It also distinguishes the result scope by saying it returns the next and previous business days, which separates it from sibling tools like kr_list_holidays and kr_add_business_days.

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 a clear usage cue: use it before promising a delivery or meeting date. It does not explicitly name when not to use it or route to siblings, so it falls short of full alternative guidance.

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