Skip to main content
Glama
Sign In
jade-mcp

jade-mcp

by choiyounggi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

출퇴근시각 등록 요청 준비

jade_prepare_clock_request
Read-only

Prepares missed clock-in/out registration requests for selected past or current workdays by filling times, passing server validation, and returning date-by-date previews and one-time tokens without submitting.

Instructions

출퇴근을 못 찍은 지난 근무일(오늘 포함)의 출근·퇴근 시각을 JADE 출퇴근시각 등록 요청서로 상신 직전까지 채우고, 화면의 서버 검증(신청 검증·근무계획 대비 검증)을 통과시킨 뒤 날짜별 미리보기와 일회용 토큰을 돌려준다. 상신하지 않는다. 신청서는 하루에 한 장이라 날짜마다 따로 준비하고, 막힌 날은 사유와 함께 skipped 로 알려 준다. kind 로 출근만(in)·퇴근만(out)·둘 다(both)를 고르고, 고른 쪽의 시각은 사용자에게 받은 값만 넣는다(기본값 없음). 출퇴근 처리 단위로 시각이 바뀌면 adjusted 에 적는다. 사용자가 미리보기를 확인하고 승인한 뒤에만 날짜마다 jade_commit_clock_request 로 상신한다.

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": {
      "dates": "<dates>",
      "kind": "<kind>"
    },
    "name": "jade_prepare_clock_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
inHmNo출근 시각 HHMM (kind=in·both 이면 필수)
kindYesboth=출퇴근기록, in=출근기록만, out=퇴근기록만. 사용자가 말한 쪽만 고른다
datesYes근무일 YYYYMMDD 목록 (오늘 이전·오늘만)
outHmNo퇴근 시각 HHMM (kind=out·both 이면 필수)
reasonNo신청 사유출/퇴근 시간 미등록으로 인한 등록 신청
outNextDayNo퇴근이 다음 날 새벽이면 true

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only supply readOnlyHint/openWorldHint, and the description adds real behavioral context: it runs server-side 신청 검증 and 근무계획 대비 검증, returns a per-date preview plus a one-time token, reports skipped dates with reasons, and never submits. It stops short of describing token lifetime or what happens on partial validation failure across multiple dates, which keeps it from 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.

Conciseness4/5

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

Front-loaded with purpose and the '상신하지 않는다' constraint, then flows to per-date handling, kind selection and the commit handoff; nearly every sentence carries a constraint. It is a single dense paragraph, though, and the parenthetical enumeration of the two validation types is more detail than the caller needs.

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 6-parameter, 100%-covered, no-output-schema tool, the description covers the return shape (per-date preview, one-time token) and the skipped-result case that an agent must handle. The one missing link is what the one-time token is for and how it is passed into jade_commit_clock_request.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents dates, kind, inHm, outHm, reason and outNextDay; the description's added value is the rule that only user-supplied times go in with no defaults and that kind must reflect only the side the user named. Notably it references an 'adjusted' field that does not exist in the input schema, which can mislead an agent, and it says nothing about reason or outNextDay.

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?

Names a specific verb+resource (fills the JADE 출퇴근시각 등록 요청서 draft) and states the exact scope (missed workdays including today, one form per day). It also explicitly separates itself from the commit sibling by stating '상신하지 않는다' and pointing to jade_commit_clock_request, so an agent can distinguish it from a submission tool without opening a 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?

Gives concrete when-to guidance: prepare per date because there is one form per day, blocked days come back as 'skipped' with a reason, and submission happens only after the user approves the preview. The gap is that the other prepare sibling jade_prepare_punch is never mentioned or contrasted, so the agent gets no rule for choosing between the two attendance-preparation tools.

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