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

Annotations only reveal readOnlyHint=false and destructiveHint=false. The description adds substantial context: it acts 'as them', attaches the case for the team, opens the support chat, and discloses failure behavior ('Check `sent`: when it is false nothing reached the team'). This is behavioral detail well beyond 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?

Front-loaded with the core action, then usage rules, then the important `sent` caveat. All sentences earn their place, though the enumeration of trigger cases is dense. Slightly long but efficiently structured.

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?

With no output schema, the description compensates by explaining the side effects (opens a support conversation, opens chat) and how to verify success via `sent`. Combined with the explicit usage policy, an agent has everything needed to call this correctly.

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%, so the schema already documents all six parameters (kind, found, tried, chatid, reason, question). The description adds only a soft implication that 'the case' is built from found/tried, and introduces the `sent` field which is a return value rather than a parameter. Baseline 3 is appropriate when the schema carries the load.

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?

States a specific verb+resource ('Hand the question to the support team with the case written') and a customer-facing benefit. Clearly distinguishable from sibling communication tools like send_feedback or send_team_feedback, since it opens a support conversation on the customer's behalf.

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?

Gives an explicit allow-list ('ONLY when a person must act: they asked for a person, a refund, a legal or privacy request, something broken..., money moved, account access') and an explicit exclusion ('Never to avoid a hard question'). The when/when-not criteria are unusually complete.

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