연장근무 신청 상신

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 covered structurally. The description adds genuinely new behavior: a server-side re-validation pass immediately before submission, and the fact that the request goes straight to approvers with real-world visibility. It stops short of saying what happens when validation fails or whether a retry is safe, so not 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.

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

Three short sentences ordered by importance: what it does, how it validates, and the approval constraint that gates the call. Every sentence adds a distinct fact with no repetition.

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-param commit tool in a prepare/commit family, the description covers the source of the token, the pre-submit validation, and the user-approval requirement, which is the full decision surface. It omits failure/retry behavior, but with destructiveHint and non-idempotent annotations already present that is a minor gap.

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 there is a single required token param, so the schema carries the semantics. The description only restates that the token originates from jade_prepare_overtime, which the schema already says verbatim. Baseline 3 applies.

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?

Names a specific verb (상신/submit to approval line) and resource (연장 근무 신청서/overtime application), and explicitly ties it to the sibling jade_prepare_overtime that produces the token. An agent can distinguish it from jade_prepare_overtime or jade_commit_vacation 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.

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

States the prerequisite (token from jade_prepare_overtime) and the gating condition for invocation: only after the user has reviewed the preview and explicitly approved. This is an explicit when-to-use rule that rules out speculative calls, which is exactly what a commit tool needs.

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