Skip to main content
Glama
jade-mcp
by choiyounggi

신청서 삭제·회수 준비

jade_prepare_delete_applications
Read-only

Validates selected applications for deletion or retraction using JADE eligibility and approval rules, then returns a preview and one-time token for later commit without deleting.

Instructions

신청서(APPL_ID) 여러 장의 삭제(delete) 또는 회수(retract)를 준비한다. 신청내역에서 다시 찾고, 신청서 화면을 열어 JADE 화면의 버튼 규칙(임시저장이거나 아직 결재 전인 신청서만 삭제, 회수는 회사가 회수 기능을 쓸 때 결재 전 신청서만)과 결재 진행 검사를 통과한 것만 대상으로 잡아 미리보기와 일회용 토큰을 돌려준다. 지우지 않는다. 막힌 신청서는 blocked 에 사유와 함께 알려 준다. 삭제는 신청서를 지우고 되돌릴 수 없다. 회수는 결재 요청만 거둬들이고 신청서는 남는다. 사용자가 미리보기를 확인하고 승인한 뒤에만 jade_commit_delete_applications 로 실행한다.

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": {
      "applIds": "<applIds>",
      "action": "<action>"
    },
    "name": "jade_prepare_delete_applications"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYmdNo대상을 찾을 신청일 종료 YYYYMMDD (기본: 오늘)
actionYesdelete=삭제(되돌릴 수 없음), retract=회수. 사용자가 말한 쪽을 고른다
applIdsYes대상 신청서 번호(APPL_ID) 목록 — jade_applications 결과의 applId
fromYmdNo대상을 찾을 신청일 시작 YYYYMMDD (기본: 6개월 전)

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 with that — it explicitly says it does not delete anything and returns a preview plus a one-time token. Beyond the annotations it discloses substantial behavior: the button-rule eligibility checks, approval-progress validation, that blocked applications are reported with reasons in 'blocked', that delete is irreversible while retract only withdraws the approval request and leaves the application intact.

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 the core action and the non-destructive guarantee, with the eligibility rules and handoff to the commit tool following in a logical order. The middle sentence bundling the button rules and approval check is dense and slightly run-on, but no sentence is filler.

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, so the description must explain returns — and it does: a preview, a one-time token, and a 'blocked' collection with reasons. Combined with the irreversibility distinction between delete and retract, an agent has everything needed to call this safely.

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 meaning: it explains that the date-range parameters are used to re-locate the applications in application history, and that applIds are the application numbers surfaced by the applications list, plus that the action must match what the user asked for. Minor gain over the schema's own field descriptions.

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 names a specific verb and resource — preparing deletion or retraction of multiple applications (APPL_ID) — and explicitly separates this from the commit step: '지우지 않는다' and only after preview approval does jade_commit_delete_applications run. An agent can immediately distinguish it from jade_commit_delete_applications and jade_applications without opening any 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?

It states the exact preconditions for eligibility (temporary-save or not-yet-approved applications for delete; pre-approval only and only when the company uses the retract feature) and the workflow gate: the user must review the preview and approve before calling jade_commit_delete_applications. The alternative tool is named with the condition that selects it.

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