재택근무 취소 신청 상신 (한 날)

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely new behavior: it reopens the screen, re-runs validation immediately before submitting, and only sends when output matches the preview, plus the fact that it goes straight to the approver. It does not say whether the token is single-use, which would matter given non-idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences, front-loaded with the action, then the validation guarantee, then the approval gate. Every sentence carries information, though the token prerequisite is stated twice (in the first sentence and again in the schema-facing phrasing).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema mutation tool this covers the essential chain: prepare token, preview approval, submit, re-validate. Remaining gaps — error/validation-mismatch behavior and token consumption — are secondary but relevant for a destructive, non-idempotent call.

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

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

Schema description coverage is 100% and the single token parameter is already documented in the schema as the value returned by jade_prepare_remote_work_revert. The description restates the same linkage without adding format, lifetime, or reuse semantics, so it meets but does not exceed the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (상신한다 / submit to approval line) and a specific resource (근무유형 되돌리기 재택 근무 신청서 – a remote-work-type revert application), and ties it to the producing sibling jade_prepare_remote_work_revert. It is clear enough to separate from jade_prepare_remote_work_revert, but it never explicitly contrasts with jade_commit_remote_work, which submits a different remote-work application, so sibling differentiation is only partial.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a prerequisite (a token produced by jade_prepare_remote_work_revert) and a firm invocation condition: call only when the user has reviewed the preview and explicitly approved. That acts as both a when-to-use and a when-not-to-use guard. It stops short of naming alternatives or describing what to do if validation fails.

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