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

Goes well beyond the annotations: per-address and per-brief question quotas, deduplication behavior, irreversibility ('Cannot be undone'), and where the answer surfaces. One nuance is left fuzzy — the description implies a repeated identical question has no additional effect, which reads closer to idempotency than the declared idempotentHint=false, though the quota bookkeeping could explain the difference.

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-loads the core action, then dedup rule, then limits, then return value in descending importance. Every clause carries a distinct operational fact; nothing is padding.

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?

No output schema exists, but the description covers the return value ('Returns the question id') and where the answer appears ('read_brief under questions_asked'), plus failure conditions and limits. Nothing needed to call it correctly is missing.

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% (agent, brief, question are all documented with formats), so the schema already carries parameter meaning. The description reinforces 'one question' per call and the brief/chain semantics but adds no new syntax or format detail. Baseline 3 applies.

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 ('Puts one question on a brief') plus who reads it, which cleanly separates it from read_brief and write_brief. An agent can distinguish it from all siblings without opening a schema.

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 explicit when-to-use ('Read the brief first'), what happens on duplication ('the same question is not stored again and its existing answer is returned'), and the fallback once the quota is exhausted ('state your assumptions in the delivery'). Routing conditions are spelled out rather than inferred.

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