Skip to main content
Glama
jade-mcp
by choiyounggi

신청서 삭제·회수 실행

jade_commit_delete_applications
Destructive

Deletes or withdraws applications one by one using a preparation token, revalidating each and returning per-item results. Use only after user approval; deletion is irreversible.

Instructions

jade_prepare_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": {
      "token": "<token>"
    },
    "name": "jade_commit_delete_applications"
  }
}

Input Schema

NameRequiredDescriptionDefault
tokenYesjade_prepare_delete_applications 가 돌려준 토큰

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, but the description adds substantive behavior: each item reopens the application screen, re-runs validation, and is sent only if the live state matches the preview. It also enumerates the per-item result categories (deleted, retracted, skipped, failed, needs confirmation), which is information unavailable anywhere else.

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?

Three sentences, each carrying distinct payload: what it does, how it validates per item and what it returns, and the approval guardrail. Nothing is repeated and the constraint is front-loaded in the final sentence for emphasis.

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 single-token destructive commit tool with no output schema, the description covers the downstream contract (per-item statuses), the validation behavior, and the safety precondition. An agent has everything needed to decide whether and how to call it.

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?

There is a single parameter with 100% schema description coverage that already explains the token's origin, so the description cannot add much beyond confirming the same source. Baseline 3 applies when the schema already carries the parameter meaning.

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 (delete/retract applications one card at a time) and explicitly ties itself to the token produced by jade_prepare_delete_applications, so it is immediately distinguishable from that sibling. It also states that the card can be 'retracted' rather than only deleted, clarifying the operation's dual outcome.

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 precondition for invocation plainly: call only after the user has reviewed the preview and explicitly approved, because deletion is irreversible. The workflow alternative (prepare → preview → commit) is implied by identifying the prepare tool as the token source.

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