Skip to main content
Glama
jade-mcp
by choiyounggi

연장근무 신청 준비

jade_prepare_overtime
Read-only

Prepares a JADE overtime request up to pre-submission, validates it on the server, and returns a preview plus one-time token without submitting. Handles overnight end times and required holiday reward type.

Instructions

JADE 연장 근무 신청서를 상신 직전까지 채우고 서버 검증을 통과시킨 뒤 미리보기와 일회용 토큰을 돌려준다. 상신하지 않는다. 종료 시각이 시작 시각보다 이르면 익일 시각으로 본다(예: 0930 ~ 0200 → 익일 02:00). 시작·종료 시각은 사용자에게 받은 값만 넣는다(기본값 없음). 휴일 근무면 대체/보상 유형(rewardType)이 필요하다(100=연장근무시간 누적, 300=휴일대체일 미지정). 대체휴일 지정(200)은 JADE 화면에서 해야 한다. 연장근무는 근무 종료 전에 최종 결재가 끝나야 인정된다. 사용자가 미리보기를 확인하고 승인한 뒤에만 jade_commit_overtime 으로 상신한다.

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": {
      "date": "<date>",
      "startHm": "<startHm>",
      "endHm": "<endHm>",
      "reason": "<reason>"
    },
    "name": "jade_prepare_overtime"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYes근무일 YYYYMMDD
endHmYes종료 시각 HHMM. 시작보다 이르면 익일
reasonYes신청 사유
startHmYes시작 시각 HHMM (근무일 당일)
rewardTypeNo휴일 근무일 때만: 100=연장근무시간(OT) 누적, 300=휴일대체일 미지정

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, and the description is consistent, explicitly stating it does not submit and only prepares plus validates. It adds behavior annotations cannot express: server-side validation must pass, a one-time token is issued, and no default values are injected.

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?

Purpose and the non-submission guarantee are front-loaded, and every following sentence carries a distinct rule rather than filler. It is dense but not padded; minor cost is that several separate rules are packed into one paragraph without visual separation.

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?

There is no output schema, but the description states what is returned (a preview and a one-time token) and how that return value feeds the next call. For a five-parameter prepare step, nothing an agent needs in order to call it correctly is missing.

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, but the description adds real semantics: the cross-midnight interpretation is spelled out with a worked example (0930~0200 → next day 02:00), start/end must be user-supplied with no defaults, and rewardType is only required for holiday work with the value 200 explicitly excluded.

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 ('JADE 연장 근무 신청서를 상신 직전까지 채우고 서버 검증을 통과시킨 뒤 미리보기와 일회용 토큰을 돌려준다') and immediately negates the sibling behavior with '상신하지 않는다'. An agent can distinguish this from jade_commit_overtime without opening either schema.

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?

Gives an explicit sequencing rule: the user must review the preview and approve, then only jade_commit_overtime submits. It also names an out-of-scope case (대체휴일 지정 200 must be done in the JADE screen) and a real-world constraint (final approval must complete before the shift ends), so both when-to-use and when-not-to-use are covered.

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