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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, and the description's 'Risco: read · Efeitos: Nenhum' merely restates that safety profile. It adds some value by describing the payload ('totais e saldo por estadia'), but says nothing about behavior with the default type 'personalizado' or what happens when dates are omitted, which is the main behavioral unknown here.

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?

Two tight lines with the report categories front-loaded ahead of the metadata line, so an agent scanning the first clause already knows what it gets. The second line (scope/risk/effects) is largely redundant with the annotations, which is the only wasted space.

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 0% schema coverage and no output schema, the description carries the full documentation burden and falls short: it never explains the date parameters, the default 'personalizado' mode, or what 'personalizado' actually filters on. For a parameterized reporting tool this leaves an agent unable to construct a correct call without guessing.

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%, so the description must carry parameter meaning and only partially does: it names the enum values of `type` in natural language and hints at a period filter via 'do período'. The start_date and end_date parameters are never mentioned — no format, no optionality, no interaction with 'personalizado' — leaving two of three parameters documented only by the bare 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?

The description names the resource precisely by enumerating the report categories (arrivals, departures, active stays, cancellations, custom period filter) and the output content (totals and balance per stay), so an agent knows exactly what it returns. It does not, however, distinguish itself from report siblings such as get_occupancy_report, get_performance_report or get_cashflow, which is what separates a 4 from 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?

Usage is only implied through the enumeration of report types: an agent can infer that it should pick 'chegadas' for arrivals, 'cancelamentos' for cancellations, etc. There is no explicit statement of when to prefer this tool over the other report tools, no prerequisites, and no exclusions.

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