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

Annotations are all false hints, so the description carries the full burden, and it delivers: it discloses that original conversation text is never sent, that satisfaction feeds next-day graph supplementation, that unobserved reactions must not be guessed, and that satisfied=true still requires an adoption summary. No contradiction with annotations exists.

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 long but densely packed, with ★ markers highlighting the highest-risk rules and a clear front-loaded purpose statement. Some redundancy exists between the ★★★ block and the schema's comment description, but the structure makes the nuanced conditions scannable and every section earns its place.

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 tool with subtle conditional requirements and five parameters, the description covers the call timing, data handling, mapping rules, non-guessing constraint, and downstream effect. Since an output schema exists, the absence of return-value discussion is not a 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?

Even though schema coverage is 100%, the description adds critical inter-parameter logic: query_id takes priority over question_text, issue_type is required only when dissatisfied, and comment has asymmetric rules depending on satisfied. This goes well beyond the schema's per-field descriptions and materially helps an agent construct valid arguments.

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 and resource: it records the user's reaction to the prior Den response as a summary-level relay tool, not a direct user-input form. It also explicitly distances itself from query tools ('이 도구는 질의가 아니다 — 답을 찾으려면 k_snippets·answer_why를 쓴다'), which cleanly differentiates it from siblings.

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 states when to call it (after using the immediate prior Den response, before the conversation ends), how to handle query_id vs question_text fallback, and when to set satisfied/issue_type. It also gives an explicit exclusion: when the agent needs an answer, use k_snippets or answer_why instead.

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