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

Beyond the annotations (destructiveHint=true), the description discloses the consent requirement, the obligation to set `consented` only after asking, the need to quote the user verbatim, and a prohibition on inventing feedback. It also notes that a declined reaction stays in the conversation, adding behavioral nuance not available from structured fields.

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 dense but every sentence carries essential instruction. It could be more tightly structured, but the details about consent and verbatim quoting are critical. It is appropriately sized for a tool with ethical and quality constraints.

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 that transmits user feedback, the description covers the full workflow: consent, exact quoting, tool identifiers, and what to do when consent is withheld. No output schema exists, but the tool's action is sufficiently specified. The description is complete for an agent to use it correctly and avoid misuse.

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 schema coverage is 100%, the description adds crucial semantic context: it explains how `consented` must be true only after explicit permission, that `in_their_words` must be the user's exact sentence, and how `about`, `track_id`, and `brief` relate to the feedback context. This goes far beyond the schema's property descriptions.

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 opens with a specific verb and resource: 'Send AINSOF what the user thought of an answer', followed by concrete examples that clarify the tool's scope. It is clearly distinct from sibling tools like search_music or deliver_score, since none of those describe sending user feedback.

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 explicit, imperative guidance: 'ASK THEM FIRST, every time', 'Send only if they say yes', and 'If they decline or do not answer, do not call this tool at all'. This provides clear when-to-use and when-not-to-use conditions, going beyond mere context.

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