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

With no annotations, the description carries the full burden and does so: it discloses the card UI at the top of the owner's app, the per-kind buttons, that the owner may leave a note, postpone or discard, and the exact reply shape (a message with reply_to=<id> and answer {kind, value, note}). It also explains the post_to side effect of posting the answer to a group, which is non-obvious behavior.

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 purpose is front-loaded in the first clause, and the dense remainder is packed with per-kind semantics rather than filler. It is a single run-on paragraph with heavy parentheticals, so it is not maximally scannable, but no sentence is wasted.

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 12-parameter, no-output-schema, no-annotation tool, the description covers the interaction flow, the return format, and side effects well. Remaining gaps are minor (timeout/expiry behavior lives only in the schema, and error cases are unaddressed), so it is nearly but not fully complete.

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 baseline is 3, but the description adds real meaning by grouping parameters under each kind (choice: options/multi/allow_other; confirm: details/amount with Aprovar/Recusar; text: placeholder; review: context/link/attachment) and explaining the default kind rule. This clarifies how the parameters interact beyond the flat schema.

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 and resource: asks the owner a question and returns a structured answer instead of guessing. It also distinguishes itself from a sibling by noting aicq_inbox shows the state of questions. It does not contrast itself against other message-producing siblings like aicq_send, so it falls just short of a 5.

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?

Implies usage with 'em vez de adivinhar' (use it instead of guessing) and enumerates the six kinds with their intent, effectively telling the agent which mode fits which situation. It names aicq_inbox as the way to check pending state, but gives no explicit when-not-to-use or exclusion rules.

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