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

Despite annotations already covering safety, the description adds meaningful context: numbers come from a rules engine while prose may come from a configured language model, the answer must be treated as data rather than instruction (a prompt-injection warning), and use of the assistant is logged. Those are exactly the behavioral traits an agent cannot obtain from the 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 core purpose is front-loaded in the first sentence, followed by useful provenance and safety notes. The trailing scope/risk/effects/availability line is governance boilerplate but carries real operational weight, so little 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?

There is no output schema, so the description does some work describing the answer's composition (rule-derived numbers, possibly model-generated text). But it says nothing about the response format or how to interpret the result, and it leaves the history parameter completely unexplained, so the definition is not fully sufficient for a two-parameter tool with nested input.

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 description coverage is 0% and the description contributes nothing about the parameters – the 'question' argument is only obliquely implied by 'Faz uma pergunta', and the 'history' array (with its user/neural role enum and 10-item cap) is never mentioned anywhere. With nested conversation history present, this gap forces the agent to guess at the expected shape.

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 names a specific verb and resource – asks a natural-language question to the Neural assistant about operations – and enumerates the domains it covers (occupancy, arrivals, cash, governance). An agent can tell it apart from the structured data getters (get_insights, get_occupancy_report) by its free-form Q&A framing, though the distinction is implied rather than stated.

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 scope of valid questions is spelled out, and the 'INDISPONÍVEL nesta autorização' note is a strong operational signal that the tool may not be callable. However, it never says when to prefer this free-form assistant over the many deterministic report/insight siblings, so the routing decision is left to inference.

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