Skip to main content
Glama
jade-mcp
by choiyounggi

휴가 신청 준비

jade_prepare_vacation
Read-only

Prepares a JADE vacation request with date and time range, validates it on the server, and returns a preview plus one-time token for later submission without submitting it.

Instructions

JADE 휴가 신청서(시간 단위, 하루 안의 시각 범위)를 상신 직전까지 채우고 서버 검증을 통과시킨 뒤 미리보기와 일회용 토큰을 돌려준다. 상신하지 않는다. 반차는 그날 실제 근무 시각 기준으로 쉬는 구간을 넣는다 (예: 10시 출근 오후 반차 → 15:00~19:00). 사용자가 미리보기를 확인하고 승인한 뒤에만 jade_commit_vacation 으로 상신한다.

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

Input Schema

NameRequiredDescriptionDefault
dateYes휴가일 YYYYMMDD
endHmYes종료 시각 HHMM
reasonYes신청 사유
startHmYes시작 시각 HHMM
attendClassNo휴가 종류 코드. 4010=연차휴가4010

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavior — server-side validation must pass, a preview and a one-time token are returned, and no submission occurs. It does not disclose token lifetime or whether the token is bound to a specific payload, which matters for a two-step prepare/commit flow, so it falls short of a 5.

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?

Four short sentences, front-loaded with the core action and the non-submission guarantee, followed by the rule most likely to be gotten wrong (half-day time computation) and the handoff instruction. No 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 5-parameter prepare tool with no output schema, it covers purpose, the domain trap, and the downstream step. The main residual gap is that the returned preview/token shape is unspecified, though the absence of an output schema limits how much the description could reasonably be expected to say.

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 genuine meaning beyond the schema by explaining that startHm/endHm for half-days must reflect the actual working hours (e.g., 10:00 start with afternoon half-day → 15:00~19:00), which the schema's plain HHMM descriptions do not convey.

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 (fills a JADE vacation application, time-of-day granularity, up to submission), plus what it explicitly does NOT do (상신하지 않는다). That negative clause cleanly separates it from jade_commit_vacation without the agent needing to open 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 workflow condition: only call jade_commit_vacation after the user reviews the preview and approves. It also names the alternative tool by name, so the prepare-vs-commit routing decision is fully resolved.

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