feedback

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that raw conversation text is never sent, that summaries are limited to 200 characters, that satisfaction must not be inferred, and that a counterfactual phrase must never be invented. It even explains the downstream consequence of the data and the distinction between 'using den' and 'changed because of den'.

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 front-loaded with the core purpose and organized with star-bulleted rules for the delicate comment requirements. Some repetition occurs around not guessing or inventing the counterfactual phrase, but this emphasis is purposeful for a tool where hallucinating feedback would be harmful.

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?

Given the tool's complexity, the absence of annotations, and the need to capture nuanced user feedback ethically, the description is complete: it covers purpose, invocation timing, parameter selection rules, content restrictions, and downstream use. Since an output schema exists, not describing the return value is acceptable.

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?

Although the schema already covers all parameters, the description adds critical relational meaning: query_id is preferred over question_text as a fallback, issue_type is only recorded when dissatisfied, satisfied=true requires an adoption line in comment, and the counterfactual part is only included when the user actually stated it. These conditional rules cannot be inferred from the schema alone.

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 defines the tool precisely as a 'relay tool' that records the user's reaction (correction, complaint, adoption, ignoring) after the calling agent uses the prior Den response, and it explicitly contrasts itself with a user-facing form. This verb+resource+scope framing makes its role distinct from the sibling Den answer tools even though it never names them.

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 clearly states when to record ('대화 종료 전', after the preceding Den response) and gives explicit when-not guidance: do not guess satisfaction if no observable reaction exists. It also defines mapping rules from user behavior to satisfied/issue_type, though it does not explicitly name an alternative tool for comparison.

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