Skip to main content
Glama
Sign In
jade-mcp

jade-mcp

by choiyounggi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

근무일정 등록 준비

jade_prepare_schedule
Read-only

Prepare monthly work schedule changes by setting all or selected workable dates to the same start/end time, returning a preview and one-time token without saving; commit only after user approval.

Instructions

「내정보 > 근태현황 > 일정등록」에서 한 달의 근무 가능일자를 모두(또는 dates 로 고른 날만) 같은 계획 시각으로 바꿀 준비를 하고 미리보기와 일회용 토큰을 돌려준다. 저장하지 않는다. 결재 없이 바로 반영되는 변경이므로 사용자가 미리보기를 확인하고 승인한 뒤에만 jade_commit_schedule 로 저장한다.

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": {
      "month": "<month>",
      "startHm": "<startHm>",
      "endHm": "<endHm>"
    },
    "name": "jade_prepare_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
datesNo일부 날만 바꿀 때 YYYYMMDD 목록. 없으면 근무 가능일자 전체
endHmYes계획 종료 시각 HHMM
monthYes대상 월 YYYYMM
startHmYes계획 시작 시각 HHMM

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that nothing is persisted, that it returns a preview plus a one-time token, and that the underlying change would apply immediately without an approval step. Those are exactly the behavioral traits an agent needs before deciding to call it, and they are consistent with readOnlyHint=true.

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?

Two tight sentences, front-loaded with what it does and the UI location, then the safety constraint about committing. Every sentence carries weight; the embedded UI path is slightly verbose but useful for locating the feature.

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?

For a prepare/commit pair with no output schema, the description covers what is produced (preview and one-time token), what is not persisted, and how the flow continues. Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100%, so month/startHm/endHm/dates are already documented. The description adds only the aggregate behavior that dates selects a subset while its absence means all workable days, which largely restates the schema's own 'none means all workable days' note. Baseline 3 is appropriate.

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 (prepare a monthly work-schedule change at a given planned time), names the exact UI path, and explicitly distinguishes itself from jade_commit_schedule, which does the saving. An agent can tell it apart from its sibling without opening the 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?

Explicitly says it does not save, that the change takes effect without approval, and that jade_commit_schedule should only be called after the user confirms the preview and approves. That is a clear when-to-use / when-to-follow-up rule with the alternative named.

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