preview_save_minutes

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so no credit for those. The description adds genuinely useful context: the token is a hash of (note_id, text) so the approved content cannot diverge from what is saved, and the token does NOT substitute for user approval — the approval_request must be shown and explicit consent obtained. This is material behavioral disclosure not present in the annotations.

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?

The description is front-loaded: purpose in the first line, then the critical behavioral rules, then Args/Returns. The Args block in the description is somewhat redundant with the fully-covered input schema, which costs a little efficiency, but every other sentence earns its place and the Returns section usefully enumerates the response fields.

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 4-parameter tool with an output schema present and full schema description coverage, the description covers the essentials: purpose, pipeline position, token semantics, and the mandatory user-approval handoff before calling save_approved_minutes. Slight room remains on what an agent should do on a NEEDS_REVISION status, but nothing blocks correct invocation.

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 coverage is 100% and each parameter already has a meaningful description in the schema, including usage guidance for include_preview ('이미 초안을 들고 있다면 False로 두어 컨텍스트를 아끼세요'). The description's Args block largely mirrors the schema verbatim, adding marginal value beyond the structured field definitions.

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 opening line states a specific verb plus resource: '저장 대상·변경 내용·검증·근거 결과를 한 번에 보여 주고 승인 토큰을 발급합니다' (shows save target/changes/validation/grounding and issues an approval token). The follow-up '저장 직전의 단일 관문입니다' (the single gateway before saving) positions it against siblings, clearly distinguishing it from save_approved_minutes and validate_minutes_draft.

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?

The description gives clear workflow context: it is the mandatory single gate before saving, the token is issued only when structural validation passes, and save_approved_minutes should be invoked only after explicit user approval. It does not enumerate exclusions for other siblings like diff_minutes_against_saved or validate_minutes_draft, but it does identify the pipeline position and the next tool.

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