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

Beyond the annotations it discloses the two-phase safety model (prepare, then confirm), that authentication comes exclusively from the connected Gover account and credentials must never be passed as arguments, that payment data is never sent here, and that large results are fetched via gover_ler_resultado with the returned resultadoId. The only wobble is that destructiveHint=true sits awkwardly next to 'sem executa-la', though as a prepare step in a destructive flow this is defensible.

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 purpose in the first sentence, then the required workflow, then caveats. Sentences are reasonably tight, though the credential and payment warnings are boilerplate that could be compressed; nothing is wasted enough to hurt.

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?

The workflow, auth constraints, and result-retrieval path are well covered, which matters for a 12-parameter tool with no output schema. However, with zero parameter documentation anywhere and no output schema, the definition leaves a real invocation gap for an agent trying to fill in the fields.

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?

Twelve parameters with 0% schema description coverage, and the description compensates with only 'Os campos seguem o contrato da API' — a punt that explains nothing about hotelId, cidadeId, quartoXpax, ofertaManual, or how IDs are obtained. An agent gets no guidance on the semantics of any parameter from either source.

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 ('Adicionar hotel ao carrinho') and the title adds the crucial qualifier 'Preparar', distinguishing it from the sibling add-to-cart tools for vehicles and flights and from the actual execution step. An agent can tell what this does without opening the 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 a clear operational flow: prepare the action, show the parameters to the user, and only call gover_confirmar_operacao after explicit confirmation — naming the alternative explicitly. It does not state when *not* to use it (e.g. when the item is already in the cart), so it stops short of the top band.

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