Gover MCP

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

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the safety profile is covered. The description adds value by clarifying that extensive data remains accessible via resultadoId and caminho, and reiterating that it doesn't alter records. It could say more about what the summary contains, but it meaningfully supplements the annotations.

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 short sentences, front-loaded with the summary purpose and followed by a useful note on extended data access. No wasted words.

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 two-parameter read-only tool with no output schema, the description gives a decent sense of what is returned (status, products, pending, next steps) and mentions a mechanism for extended data. However, with 0% schema coverage on parameters and no output schema, it should do more to explain the inputs and the shape of the returned summary.

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%; neither parameter (solicitacaoId, incluirOfertas) is described in the schema, and the description does not explain them either. The mention of resultadoId and caminho is unrelated to the two actual parameters. The description fails to compensate for the zero schema coverage.

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 (resume/summarize) and resource (the trip request of the connected account), covering status, products, pending items and next steps. It is clear what it does, though it does not explicitly differentiate itself from siblings like consultar_solicitacao or detalhar_solicitacao_completa.

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 implied: use this to get a summary of a request's state. However, there is no explicit guidance on when to prefer this over consultar_solicitacao, detalhar_solicitacao_completa, or buscar_solicitacao, which all appear related. This leaves the agent to infer the choice.

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

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.

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

Annotations declare destructiveHint=true, readOnlyHint=false, non-idempotent, open world; the description adds genuinely new behavior beyond those flags: a two-phase prepare/confirm workflow, the prohibition on passing credentials or auth identity, and the constraint that new payment data must be entered only in the Gover portal. It still does not disclose what side effects the eventual confirmed operation has on the cart or what the prepare step returns, so it is not fully complete.

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 and the prepare/confirm contract are front-loaded, and subsequent sentences each carry operational value (auth constraint, result pagination, payment data). Several sentences read as reusable boilerplate shared across the Gover tool family, which slightly dilutes focus, but there is no significant 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?

The workflow, auth, and result-retrieval context are well covered, which is appropriate given the destructive annotations and the absence of an output schema. However, for a tool with 13 parameters, a deep nested object, and 0% schema description coverage, the complete absence of parameter guidance leaves an agent under-informed about how to construct the call correctly.

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% across 13 top-level parameters and a large nested formOfertarManual object with dozens of subfields, so the description carries the full explanatory burden. It offers only the meta-statement 'Os campos seguem o contrato da API' and a payment-data caveat, which names no parameter and clarifies no field's meaning or required-value semantics. This is a major gap for a tool whose only required field is veiculoId while the rest of the surface is opaque.

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 opening sentence gives a specific verb (adicionar) and resource (veiculo ao carrinho), and the scope is immediately distinguishable from the sibling tools gover_adicionar_hotel_carrinho and gover_adicionar_voo_carrinho. The second sentence adds the critical qualifier that this is a preparation step ('Prepara a acao, sem executa-la'), which further disambiguates it from the actual mutation path.

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?

It explicitly routes execution to a named alternative ('somente depois de confirmacao explicita use gover_confirmar_operacao') and routes large payloads to gover_ler_resultado with the resultadoId. It also names the Gover-connected account as the only permitted auth context and bans credential arguments. It does not, however, state when this tool should NOT be used (e.g., a precondition on the cart existing or a prior search step), so it falls short of full when/when-not coverage.

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

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

The description contradicts the annotations. It explicitly says 'Prepara a acao, sem executa-la' (prepares the action without executing it), while the annotations declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true. If the tool does not execute the action, destructive behavior is inconsistent with the stated 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 description is front-loaded with the core purpose and then structured into workflow, security, and result-handling instructions. Most sentences earn their place, though it is somewhat dense for the amount of information provided.

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 description covers authentication, preparation-vs-execution workflow, and long-result handling, but with 14 undocumented parameters and no output schema, it leaves critical invocation details unspecified. The contradiction with the destructive annotation further undermines completeness.

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?

There are 14 parameters and schema description coverage is 0%. The description provides no meaning for any parameter beyond saying the fields follow the API contract and not to pass credentials. It does not compensate for the complete lack of schema documentation, leaving the required itemSelecionadoId and all other fields semantically opaque.

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 states a specific verb and resource: 'Adicionar voo ao carrinho,' and adds the crucial scope that it only prepares the action, not executes it. This distinguishes it from siblings like gover_adicionar_hotel_carrinho and gover_adicionar_veiculo_carrinho by resource, and from gover_confirmar_operacao by workflow stage.

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?

It gives explicit workflow guidance: show parameters to the user and only after explicit confirmation use gover_confirmar_operacao. It also names the alternative tool for long results (gover_ler_resultado) and states the authentication constraint.

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

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

Annotations already declare destructive=true, openWorld=true and non-idempotent, so the safety profile is covered. The description adds genuinely non-obvious behavior: the tool prepares but does not execute, it requires downstream explicit confirmation, it ignores credentials, and its fields must conform to the API contract. It stops short of describing side effects of the eventual change or permission failures.

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 action and the prepare-vs-execute model, and most sentences carry distinct operational value (confirmation loop, credential prohibition, resultadoId routing). The trailing note about payment data in the Gover portal is tangential but still a useful boundary.

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 complex, destructive mutation with no output schema and a nested, fully undocumented payload, the workflow and safety guidance are solid, but nothing explains what the nested fields mean or which are required for an alteration. An agent would have to guess at the payload shape.

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 single 'form' parameter is a deeply nested object with roughly fifteen candidate fields (centroDeCustoId, acao, gestores, etc.), none of which are documented. The description only says fields 'follow the API contract', which adds no meaning an agent can act on, so the nested structure is essentially opaque.

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+resource ('Alterar centro de custo') and immediately qualifies it as the preparation half of a two-phase mutation, explicitly naming gover_confirmar_operacao as the execution step. This distinguishes it cleanly from the confirm sibling and from the read sibling gover_consultar_centro_custo.

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 the full operating procedure: show parameters to the user, obtain explicit confirmation, then call gover_confirmar_operacao; and route to gover_ler_resultado with the returned resultadoId when output is large. It also states two exclusions – never pass credentials as arguments, and fill new payment data only in the Gover portal.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds substantial context beyond them: the two-phase prepare/confirm flow, that it does not execute on its own, that auth uses only the connected account, that credentials must never be passed as arguments, and that large results come back via gover_ler_resultado. It does not describe rate limits or the concrete side effects of the eventual change.

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?

Purpose and the prepare-then-confirm rule are front-loaded, and each subsequent sentence (auth, result handling, payment data) carries distinct information. Slightly long due to stacked disclaimers, but nothing is pure filler.

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?

Covers workflow, auth, result handling, and a payment-data restriction well for a prep/mutation tool, and no output schema exists to explain. However, with a complex undocumented nested schema it fails to give any field-level context, leaving a real gap for correct invocation.

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 0% and the single parameter is a deeply nested "form" object with many inner fields (opcaoId, formData.ativo/nivel/unidade, clienteId, etc.). The description only says fields "seguem o contrato da API," which adds no meaning for any parameter, leaving the agent with no field-level guidance.

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+resource ("Alterar departamento") and clarifies it is a preparation step that does not execute, which separates it cleanly from the confirmar_operacao sibling. It does not explicitly contrast with the other alterar_* or incluir_departamento tools, but the resource name makes the target unambiguous.

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 workflow: prepare now, show parameters to the user, and only call gover_confirmar_operacao after explicit confirmation. It names the follow-up tool and states a precondition (explicit confirmation), though it gives no explicit when-not guidance versus sibling alter/incluir department tools.

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

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

Annotations already declare destructive/non-idempotent/openWorld, so the bar is lower, and the description adds substantial context beyond them: this is a two-phase prepare action that does not execute, credentials must never be passed as arguments, pagination is via resultadoId, and new payment data must be entered only in the Gover portal. Note the mild tension between 'sem executa-la' and destructiveHint=true, but it describes the preparation step rather than contradicting the annotation.

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, then ordered workflow constraints, each sentence carrying a distinct rule (confirmation, credential ban, pagination, payment data). Slightly verbose but no dead weight; the repetitive 'Alterar funcionario' opener mirrors the title.

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, credential and payment restrictions, and result-retrieval path are well covered, which is valuable for a complex mutation. However, with a deeply nested schema at 0% description coverage and no output schema, the definition leaves the agent without any guidance on the form's many fields, which is the main thing it needs to call this tool correctly.

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 single top-level parameter wraps a large nested object with dozens of undocumented fields. The description only says 'os campos seguem o contrato da API', which provides no field-level meaning, so it fails to compensate for the near-total absence of parameter documentation.

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+resource (alterar funcionario) and adds the crucial qualifier that it only prepares the action without executing it. It does not explicitly differentiate itself from sibling mutations like gover_incluir_funcionario or gover_alterar_centro_custo, but the prepare/confirm framing makes its role identifiable.

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?

Explicitly routes the agent: show parameters to the user, and only after explicit confirmation call gover_confirmar_operacao; for large outputs use gover_ler_resultado with the returned resultadoId. This names the follow-up tools and the condition for each, though it never states when NOT to use this tool.

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

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

Annotations declare destructiveHint=true and non-idempotent, open-world behavior, and the description adds meaningful beyond-annotation context: it is a two-phase prepare/confirm flow, credentials must never be passed as arguments, and payment data is only editable in the Gover portal. The "prepares without executing" framing reconciles with the destructive annotation rather than contradicting it.

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?

Purpose and workflow are front-loaded, but the text drifts into tangential rules (payment data in the portal, extensive-result handling) that are loosely related to altering a unit. Several sentences could be trimmed or reordered for tighter focus.

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 no output schema, the mention of using gover_ler_resultado with the returned resultadoId is a useful completion detail. However, given the 1-param deeply nested object at 0% coverage, the description leaves the agent without enough information on the payload structure to call the tool confidently.

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?

There is a single deeply nested `form` object with dozens of fields and 0% schema description coverage, so the description carries the full documentation burden. Instead it only says "Os campos seguem o contrato da API," which explains nothing about any field, and none of the nested properties (cnpj, unidadeId, tipoPagamentoId, etc.) are clarified.

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 states a specific verb+resource ("Alterar unidade") and the title clarifies it is a preparation step ("Preparar: Alterar unidade"), distinguishing it from gover_incluir_unidade and gover_consultar_unidade. The distinction is reasonably clear, though it relies partly on the title rather than the description alone.

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?

It gives explicit workflow guidance: prepare without executing, show parameters to the user, and only after explicit confirmation call gover_confirmar_operacao. This names the next-step alternative and a condition for invoking it, though it gives no guidance on when to choose this over other alterar_* tools.

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

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

Beyond the annotations it discloses that the tool only prepares the action without executing it and that execution requires a separate confirmation call. It also adds operational constraints (uses only the connected account's permissions, never pass credentials, new payment data only in the Gover portal) that the annotations do not cover.

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 action, then adds workflow, security, and pagination notes in short sentences. Slightly boilerplate on the credentials/payment lines, but each sentence carries a distinct constraint.

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 destructive, confirmation-gated approval with no output schema, the two-phase workflow and security guidance are well covered, but the meaning of the non-required parameters is left fully implicit, leaving the agent under-informed on how to populate the call correctly.

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, but it only offers 'the fields follow the API contract'. Six parameters including nivel, clienteId, justificativa, and naoAprovarProximaSolicitacao go entirely unexplained in both schema and description.

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 (aprovar) and resource (itens selecionados da solicitacao), and the title's 'Preparar:' prefix makes clear it is the prepare step, not the execution. An agent can distinguish it from reprovar/cancelar and route to gover_confirmar_operacao 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?

It gives an explicit procedural workflow: show parameters to the user, then use gover_confirmar_operacao only after explicit confirmation, and route large results to gover_ler_resultado. It does not contrast with the approve/reject/cancel alternatives directly, but the when-to-use sequencing is clear.

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

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

Annotations already declare destructiveHint=true and non-idempotent, but the description adds genuinely useful context beyond them: it is prepare-only (no execution), uses only the connected Gover account's permissions, credentials must never be passed as arguments, and new payment data must be filled in the Gover portal.

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 action and the prepare-only constraint, then layers operational rules. Every sentence carries a distinct rule; length is justified by the number of policies covered.

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 transactional flow, credential/payment policies, and result-readback routing are all covered for a destructive, open-world tool with no output schema. The remaining hole is the meaning of the nine fields, which is left entirely to the external API contract.

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% across 9 parameters, so the description carries full burden of explaining them. It only offers 'Os campos seguem o contrato da API', which explains nothing about any individual field. This is a significant gap for a 9-param tool.

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 (Atualizar) and resource (grupo de atendimento da solicitacao), and the title makes clear it is a preparation step. It distinguishes itself from write-executing siblings by declaring 'Prepara a acao, sem executa-la'.

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?

Explicit two-step workflow: show parameters to the user, and only after explicit confirmation invoke gover_confirmar_operacao. Also routes to gover_ler_resultado for long results. Clear context and a named alternative, though it never states when *not* to call it.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuinely new context: it runs under the connected Gover account's API permissions, credentials must never be passed as arguments, extensive results continue via resultadoId, and payment data is only entered on the portal. The pagination-continuation behavior in particular is not derivable from annotations.

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?

Purpose is front-loaded and the resultadoId rule is useful, but several sentences are boilerplate that read as generic policy ('Nunca informe credenciais...', 'Dados de pagamento novos devem ser preenchidos somente no portal Gover') and contribute little to invoking an airport lookup correctly.

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 simple, read-only, single-parameter search with safety already covered by annotations, the description covers auth and result-continuation adequately and hints at the resultadoId return. But with no output schema and a completely undocumented parameter, an agent still lacks the input contract needed to call it confidently.

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% for the single required 'Texto' parameter. The only compensation is the generic 'Os campos seguem o contrato da API', which explains nothing about what Texto should contain, its length limit, or matching behavior (partial name vs code). This leaves the primary input undocumented.

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 opening sentence 'Pesquisar aeroportos' is a verb+resource statement but is a literal restatement of the tool name/title, so it earns no differentiation. With ~90 sibling tools including gover_buscar_cidades_hotel and gover_buscar_bairros_hotel, nothing here tells the agent how this search differs from the other lookup tools.

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?

It gives one concrete routing rule -- for long results use gover_ler_resultado with the returned resultadoId -- which is real usage guidance. However it never says when to choose airport search over the sibling city/locale lookups, so most selection decisions are left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds meaningful extras: it uses only the connected Gover account's API permissions, requires no credentials as arguments, and points to the resultId handoff pattern. That is real added value, though it never describes result shape or pagination limits beyond the pointer.

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, which is good, but the paragraph mixes useful routing (gover_ler_resultado) with off-topic policy text about new payment data being entered only in the Gover portal that does not help an agent call this tool.

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?

A 7-parameter tool with no output schema, 0% parameter documentation, and no explanation of the return contract. The description gestures at the resultId delegation pattern but leaves most of what an agent needs to populate the call unspecified.

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 0% across 7 parameters, so the description carries the full burden and largely fails it. 'Os campos seguem o contrato da API' is a non-answer: termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto and finalidadeViagemId are never explained, and only the city scoping is implied by the title.

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 clear verb+resource ('Pesquisar bairros') scoped by city, which fits the naming contract. However, it does not distinguish itself from closely related siblings such as gover_buscar_cidades_hotel or gover_buscar_referencias_hotel, leaving the agent to infer the boundary between city-level and neighborhood-level lookups.

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 description routes the agent to gover_ler_resultado with the returned resultId for extensive results, which is genuinely useful. But it gives no explicit when-to-use/when-not guidance relative to the neighboring search tools, and the closing sentence about payment data is unrelated to invocation.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description's repetition that it 'Nao altera registros de negocio' is redundant. The description adds useful context beyond annotations: it uses only the connected Gover account, forbids passing credentials or auth identity as arguments, directs extensive results to gover_ler_resultado, and restricts new payment data to the Gover portal. Missing rate limits or error behavior, but this is solid added context.

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 description is front-loaded with purpose and structured as short sentences, but several sentences do not earn their place for this specific tool: 'Nao altera registros de negocio' duplicates annotations, 'Os campos seguem o contrato da API' is filler, and the payment-data note seems tangential to a city search. The auth and result-handling guidance is useful, but the overall text contains avoidable generic boilerplate.

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?

Annotations provide a rich safety profile and there is no output schema, but the description still leaves a critical gap for a 7-parameter search tool: no parameter semantics whatsoever. It gives some context about auth, result pagination via resultadoId, and payment restrictions, but an agent cannot reliably invoke the tool correctly without knowing what the input fields mean or what the normal return shape is.

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?

There are 7 parameters with 0% schema description coverage, so the description must carry the burden of explaining what each one means. It only says 'Os campos seguem o contrato da API', which adds no meaning for termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, or finalidadeViagemId. An agent would have no guidance on which parameter to use or how to combine them.

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 states a specific verb ('Pesquisar') and resource ('cidades') scoped to 'hospedagem', which clearly separates it from the vehicle counterpart in the sibling list. However, it does not explicitly name or contrast the tool with alternatives such as gover_buscar_cidades_veiculo, leaving sibling differentiation implicit 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 description implies usage via its purpose sentence and provides post-call guidance ('Para resultados extensos, use gover_ler_resultado com o resultadoId retornado') along with account-permission constraints. It still lacks explicit guidance on when to choose this tool versus alternatives like gover_buscar_hoteis or gover_buscar_cidades_veiculo, so routing remains inferred rather than instructed.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered; the description adds real context beyond that — the large-result overflow pattern (resultadoId → gover_ler_resultado) and an explicit prohibition on passing credentials or auth identity as arguments. The 'Nao altera registros de negocio' line largely restates readOnlyHint, and the payment-data sentence is tangential to a city search.

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?

Purpose is front-loaded in the first sentence and each subsequent sentence is short and single-purpose. Slight waste from the readOnly restatement and the payment-data sentence, which does not apply to a city lookup.

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 no output schema and zero parameter documentation, the description leaves the agent without any way to construct a meaningful query or anticipate the response shape. Auth constraints and the pagination escape hatch are covered, but the core input semantics and return format are not.

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?

Seven parameters with 0% schema description coverage, and the description compensates with nothing — 'Os campos seguem o contrato da API' is a non-answer that explains no field. termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto and finalidadeViagemId remain completely uninterpretable from both schema and description.

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+resource ('Pesquisar cidades para locacao') that clearly identifies the vehicle-rental city lookup, distinguishing it in domain from gover_buscar_cidades_hotel. It does not, however, name or explicitly contrast the sibling search tools, so an agent must infer the boundary from the 'locacao' qualifier alone.

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?

Provides one concrete usage rule — if results are extensive, call gover_ler_resultado with the returned resultadoId — which is genuinely actionable. However, there is no guidance on when to reach for this tool versus gover_buscar_cidades_hotel, gover_buscar_lojas_veiculo or gover_iniciar_pesquisa_veiculo, and no prerequisites are stated beyond the implicit Gover account.

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

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

Annotations already declare readOnly/openWorld/idempotent non-destructive, so the safety profile is covered. The description adds real context beyond that: it states the operation runs only under the connected Gover account permissions, forbids passing credentials as arguments, and explains the large-result overflow pattern via resultadoId. That is substantive behavioral disclosure.

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?

Sentences are short and mostly front-loaded, but the body reads as a scattered list of policy disclaimers (credentials, payment data, business records) with some redundancy against the annotations. Efficient enough but not tight; the payment-portal rule is only loosely relevant to a read-only search.

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?

Safety and auth constraints are reasonably covered and the resultadoId overflow path is mentioned in lieu of an output schema. But for a tool with a deep nested formData object and 0% schema documentation, the description leaves the agent without any field-level guidance on how to actually construct the search request.

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 there are 8 top-level params plus a nested formData with ~17 sub-fields (checkIn, checkOut, destino, quartos, categoria, pageSize, etc.), none documented. The only param-related sentence, 'Os campos seguem o contrato da API', adds no meaning whatsoever. The description fails to compensate for a severe coverage gap.

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 opens with 'Pesquisar hoteis disponiveis', which is essentially a verbatim restatement of the title, giving a clear verb+resource but no differentiation from the many hotel siblings (gover_iniciar_pesquisa_hotel, gover_consultar_hoteis_ofertados, gover_validar_pesquisa_hotel, gover_buscar_quartos). An agent cannot tell from the text alone which hotel tool to pick. Purpose is legible but flat.

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?

It gives one routing rule – 'Para resultados extensos, use gover_ler_resultado com o resultadoId retornado' – which is genuinely useful follow-up guidance. However, it never states when to use this search tool versus the other hotel-search siblings, so selection guidance is only partial.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint. The description adds real value beyond that: it discloses the auth model (exclusive use of the connected Gover account and its API permissions), forbids passing credentials/identity as arguments, and defines the pagination hand-off to gover_ler_resultado via resultadoId. The 'nao altera registros' line is redundant with readOnlyHint but harmless.

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 and reasonably compact, but a third of the text is boilerplate governance policy (credentials, payment data) that crowds out the operationally important parameter guidance an agent actually needs.

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 search tool with no output schema, the description does cover result-size handling, auth scope and safety. It is incomplete on the seven mostly-undocumented input parameters, which is the largest gap, but the operational context it does supply keeps it at a minimum-viable level.

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% across 7 parameters, so the description must carry the burden — and it does not. 'Os campos seguem o contrato da API' is a non-explanation that gives no meaning for termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto or finalidadeViagemId, several of which are ambiguous IDs.

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 ('Pesquisar') and resource ('lojas de locadoras'), making the operation legible. It is distinguishable in spirit from siblings like gover_buscar_veiculos or gover_buscar_cidades_veiculo, but the description never explicitly contrasts with them, so it stops 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 a search/lookup use case and gives one concrete directive: use gover_ler_resultado with the returned resultadoId for large result sets. However, it never states when to prefer this over siblings such as gover_buscar_veiculos or gover_iniciar_pesquisa_veiculo, leaving usage selection to inference.

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

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

Beyond annotations (readOnly, idempotent, openWorld), it adds real operational context: it uses only the connected Gover account and its API permissions, does not alter business records, credentials/identity must never be passed as arguments, and new payment data must only be entered in the Gover portal. That is meaningful auth and data-handling disclosure.

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?

Compact and front-loaded with the action first, then constraints, then the large-result routing tip. Each sentence carries information; no filler. Slight run-together of unrelated constraints keeps it from a 5.

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 an 8-parameter, zero-coverage search tool with no output schema, the description covers behavioral and routing aspects but leaves parameter meaning and required-field guidance entirely unaddressed, which an agent needs to invoke it correctly.

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 8 parameters exist, so the description carries the burden — yet it only says 'fields follow the API contract' with no explanation of termo, opcaoId, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, or finalidadeViagemId. It also omits that opcaoId is required.

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 states a clear verb+resource (search rooms and hotel rates) matching the title. However, it does not distinguish itself from siblings like gover_buscar_hoteis or gover_iniciar_pesquisa_hotel, leaving ambiguity in a dense hotel-search tool family.

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?

It gives one explicit routing instruction — for extensive results, use gover_ler_resultado with the returned resultadoId. But it offers no guidance on when to prefer this tool over gover_buscar_hoteis, gover_iniciar_pesquisa_hotel, or gover_consultar_hoteis_ofertados.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: the auth constraint (never pass credentials as arguments), the pagination follow-up via resultadoId, and the policy that payment data belongs only in the portal. It omits return-shape and any rate/limit behavior, which keeps it short of a 5.

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 sentence and the follow-on sentences are short. A couple of the sentences (payment data, credential warning) read as boilerplate partly tangential to a read-only search, but nothing is padded to the point of noise.

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 7-parameter, zero-documented, no-output-schema search tool, the description covers behavior and follow-up retrieval but leaves every filter parameter unexplained. The mention of resultadoId partially compensates for the missing output schema, so it is minimally adequate rather than 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 description coverage is 0% across 7 parameters (termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, finalidadeViagemId), and the description only says 'Os campos seguem o contrato da API'. No parameter's meaning, accepted values, or filtering semantics are explained, so the agent gets essentially no help interpreting the 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 states a clear verb+resource ('Pesquisar pontos de referencia de hoteis'), so an agent knows it is a search operation over hotel reference points. However, it gives no differentiation from closely related siblings such as gover_buscar_bairros_hotel, gover_buscar_cidades_hotel, or gover_buscar_hoteis, leaving the exact scope of 'pontos de referencia' ambiguous.

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?

It gives a clear operational condition: results must come exclusively from the connected Gover account and its API permissions, and extensive results should be retrieved via gover_ler_resultado using the returned resultadoId. That is real routing guidance, but it never states when to prefer this tool over the competing hotel-search siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further: it states the call runs solely under the connected Gover account's API permissions, forbids passing credentials or auth identity as arguments, and explains the large-result handoff to gover_ler_resultado via resultadoId. That adds real auth and pagination context beyond the annotations.

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 leads, which is good, but several sentences are boilerplate (the credentials warning, the payment-data-in-portal note) that dilute the core lookup guidance. It is not bloated, but not every sentence earns its place for an agent deciding how to call the tool.

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 and no parameter documentation, so the description should do more; it does supply the resultadoId pagination handoff, which is valuable. Still missing: what the lookup returns, whether either key is required, and how it differs from the sibling solicitacao readers.

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 the load. It only says lookup is 'por ID ou numero interno' and that 'os campos seguem o contrato da API', without stating formats (integer vs string), that both parameters are optional, or which key to prefer. Two of two parameters remain behaviorally undocumented.

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 (buscar) and resource (solicitacao) with the two lookup keys, matching the title. It is clearly a read-one lookup, but it never names the close siblings (gover_consultar_solicitacao, gover_detalhar_solicitacao_completa, gover_filtrar_solicitacoes) that an agent must choose between in this large tool family.

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 one useful routing rule: for large results use gover_ler_resultado with the returned resultadoId, and that new payment data must be entered in the Gover portal. However, it never states when to prefer this lookup over gover_consultar_solicitacao or gover_detalhar_solicitacao_completa, so the main selection decision is left implicit.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description meaningfully extends this: it uses only the connected Gover account and its API permissions, it never alters business records, credentials/identity must never be passed as arguments, and large results are paginated via resultadoId. These are useful operational facts beyond the safety hints, though it doesn't describe the actual shape of returned vehicle data.

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 definition is short, front-loads the scope, and each sentence (auth, credential warning, pagination routing, payment restriction) carries distinct value. The opening sentence is essentially a restatement of the title, which is the only wasted line.

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 read-only search with no output schema, the description covers auth scope, safety, pagination, and a payment restriction, which is decent. But with a complex nested 8-parameter schema at 0% description coverage, the absence of any parameter guidance leaves a real gap that the description should have closed.

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% across 8 parameters, one required nested object with many sub-fields (termo, cidadeId, dtRetirada, localDevolucao, etc.). The only parameter-related text is 'Os campos seguem o contrato da API', which adds no meaning and does not compensate for the coverage gap, leaving the agent to guess at each field's semantics.

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 ('Pesquisar veiculos disponiveis'), so an agent understands this searches for available vehicles. However, it offers no differentiation from the many vehicle siblings (gover_buscar_lojas_veiculo, gover_buscar_cidades_veiculo, gover_iniciar_pesquisa_veiculo, gover_consultar_veiculos_ofertados), so the agent cannot tell which vehicle-search entry point applies.

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?

It routes the agent to gover_ler_resultado when results are extensive, which is a genuine alternative-selection rule, and it cautions that new payment data must go only through the Gover portal. But it never states when to use this tool versus the other vehicle search/init siblings, leaving the core selection decision to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior; the description adds real context beyond that: it uses only the connected Gover account and its permissions, does not alter business records, must not receive credentials, and payment data belongs in the portal. These are meaningful behavioral constraints, though return/pagination behavior is left thin.

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 description is compact and front-loads the purpose before constraints and the result-continuation pointer. A couple of clauses (payment data, credentials) read as boilerplate, but nothing is redundant enough to obstruct.

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 complex tool with nested objects, eight parameters, zero documented fields, and no output schema, the description does not explain how to build formData, what a successful result contains, or how pagination/resultadoId round-trips work. It is significantly under-specified for the tool's complexity.

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?

With eight parameters, a large nested formData object, and 0% schema description coverage, the description carries the full burden — yet it only says 'Os campos seguem o contrato da API', which explains nothing about termo, cidadeId, formData fields, or required-ness. It does not compensate for the coverage gap at all.

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+resource ('Pesquisar disponibilidade de voos'), so an agent knows this searches flight availability. However, it does not distinguish itself from close siblings like gover_buscar_voos_assincronos, gover_cotar_voos, or gover_iniciar_pesquisa_aerea, leaving the agent to guess which search entry point applies.

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?

It provides one concrete routing rule — for extensive results use gover_ler_resultado with the returned resultadoId — which is genuinely useful. But it gives no guidance on when to pick this tool versus the numerous other flight-search/cotacao siblings, so usage is only partially covered.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds that it does not alter business records and that credentials/authentication identity must never be passed as arguments, which is useful and not covered by annotations. However, it does not describe pagination, result expiry, or other async-specific behavior beyond pointing to gover_ler_resultado.

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 description is composed of short, front-loaded sentences with no wasted words. Each sentence carries a distinct instruction or constraint, though the density of security and payment notes slightly dilutes focus on the primary operation.

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 11-parameter, no-output-schema, async tool, the description covers read-only safety, credential handling, and async follow-up, but omits parameter meanings, async result lifecycle, and sibling differentiation. It is minimally adequate but leaves important operational gaps.

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 0%, so the schema documents only types and enums without meaning. The description says fields follow the API contract but does not explain any of the 11 parameters (termo, cidadeId, clientId, tipoOpcao, etc.), leaving the agent without semantic guidance for a complex parameter set.

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 states it consults asynchronous air availability using the connected Gover account, but does not distinguish this tool from siblings like gover_buscar_voos, gover_cotar_voos, gover_consultar_resultados_voos, or gover_iniciar_pesquisa_aerea. An agent cannot clearly tell when async availability is preferred over synchronous search or quotation.

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?

It hints at asynchronous retrieval by directing the agent to use gover_ler_resultado with the returned resultId for long results, but provides no explicit when-to-use or when-not-to-use guidance against alternative flight search siblings. The usage context is implied rather than stated.

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

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

Annotations already state destructiveHint=true and non-idempotency, but the description adds context they cannot convey: the action is staged rather than executed, it runs exclusively under the connected Gover account and its API permissions, credentials/identity must never be passed as arguments, and new payment data must be entered only in the Gover portal. These are material behavioral constraints beyond the annotation set.

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 sentence, followed by workflow rules, then result handling and data-sensitivity notes. Each sentence carries a distinct rule, though the credential/payment sentences could be tightened slightly.

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 two-phase prepare/confirm workflow is well explained, so the calling model knows what happens after invocation. However, with 0% schema coverage and a nested required formData object, the agent gets no help constructing the valid payload, which is the largest remaining gap for a create-style tool with no output schema.

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% across 8 top-level parameters plus an 11-field nested formData object. The only guidance is 'Os campos seguem o contrato da API', which tells the agent nothing about field meaning, formats, or the tipoPassageiro enum values. The description does not compensate for the coverage gap.

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 ('Cadastrar passageiro' = register passenger), which distinguishes it from the search-oriented sibling gover_pesquisar_passageiros. The title reinforces that this is the preparation/staging step ('Preparar:'), so an agent can tell what it 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?

Explicitly says it prepares the action without executing it, instructs to show parameters to the user, and names the exact next tool (gover_confirmar_operacao) that must be used only after explicit confirmation. It also names gover_ler_resultado for large results. This is a complete when/when-not/alternative routing.

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

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

Annotations already declare destructive=true/idempotent=false, but the description adds real behavioral context beyond them: it is a prepare-only step, it uses only the connected account's permissions, it must not receive credentials, and payment data is handled elsewhere. The 'sem executa-la' wording sits in slight tension with destructiveHint=true, though this reflects the overall cancellation flow rather than a true contradiction.

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 core purpose and the confirm-flow guidance, which is good. However, it runs several unrelated instructions together in one block and includes a payment-data note that is of dubious relevance to a cancellation tool, adding noise to an otherwise dense paragraph.

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 4-parameter, 0%-coverage tool with no output schema, the description covers the operational flow and result handling competently but leaves the parameter surface entirely unexplained. The usage workflow is complete; the field-level completeness is not.

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 0% across 4 parameters (solicitacaoId, opcaoId, clienteId, justificativa), and the description does nothing to compensate—it only offers the boilerplate 'Os campos seguem o contrato da API'. No parameter's meaning, format, or the required/optional distinction is clarified, leaving the agent dependent on undocumented fields.

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+resource (cancelar solicitacao) and immediately clarifies the crucial nuance that it 'prepara a acao, sem executa-la', which distinguishes the two-phase prepare/confirm pattern from a direct cancellation. An agent can tell it apart from siblings like gover_aprovar_solicitacao or gover_confirmar_operacao.

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?

Explicit when-and-how guidance: show parameters to the user, then only after explicit confirmation call gover_confirmar_operacao, and for large results call gover_ler_resultado with the returned resultadoId. It names the alternative tools and the conditions that select them.

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

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

Annotations already declare readOnly, non-destructive, idempotent, closed-world. The description adds real behavioral context beyond that: it only compares data as returned by prior queries in this account, and it does not assume policy or validity. That is a meaningful disclosure of what the tool does not do. It stops short of explaining limits (e.g., 50-item cap, what happens with expired references), so a 4 rather than 5.

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 short sentences, no filler, and the key scoping constraint (same account, as-returned data) is front-loaded. Every clause earns its place; nothing redundant with the schema or annotations is repeated.

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 read-only annotations and no output schema, the description need not explain return shape. But for a tool whose only input is an opaque reference structure at 0% schema coverage, the missing explanation of what references must contain is a real completeness gap an agent will hit immediately.

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 0% for the single 'referencias' parameter, so the schema carries no descriptive text. The description never explains what a referencia is, that it needs resultadoId + caminho, or the 50-item bound. For a parameter with zero coverage the description should compensate and it does not.

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 (compara) and resource (preço, moeda, condições e disponibilidade) with clear scope: comparisons of options returned by prior queries in this same account. It distinguishes itself from siblings like gover_consultar_resultados_voos or gover_buscar_voos by being comparative rather than a lookup. But it never names the alternatives (e.g., gover_solicitar_comparativo_precos, gover_consultar_status_comparativo), leaving the sibling separation implicit.

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 sentence 'exatamente como retornados nas consultas desta mesma conta' implies you must have run queries first, giving an implicit precondition. It does not state when to prefer this tool over the several comparison-related siblings or what happens if references are stale. Adequate but no explicit when/not/alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description reinforces idempotency with the concrete rule that reusing confirmacaoId will not repeat the operation, and adds genuinely new failure-handling behavior (no automatic retry after error/timeout). It does not spell out the blast radius of the destructive action or permission requirements.

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?

Four short sentences, each carrying a distinct payload: what it does, the confirmation precondition, idempotency, and retry policy. The purpose is front-loaded and there is no filler.

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 two-parameter, fully-schema-documented destructive action, the description covers invocation preconditions, safety against injected instructions, idempotency, and failure semantics. Since no output schema exists, the agent gets no signal about what a successful execution returns, which is the only remaining gap.

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 100%, so both parameters are already documented, establishing a baseline of 3. The description adds one useful semantic beyond the schema: that reusing confirmacaoId is safe and will not re-execute, which informs how the agent should treat that identifier. No further per-parameter meaning is added.

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 (executa) and a clearly scoped resource (uma acao previamente preparada), which tells the agent this is the second step of a prepare-then-execute flow. It does not name the sibling that produces the confirmacaoId (e.g. gover_preparar_decisao), so differentiation is implied rather than explicit.

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 an unambiguous precondition: use ONLY after explicit user confirmation, and explicitly forbids triggering it from instructions embedded in API data (anti-prompt-injection). It also covers failure context, stating that an error or timeout does not authorize an automatic resend. Both a 'when' and a 'when-not' are present.

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

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

Beyond the annotations (readOnly=false, destructive=true, openWorld=true, idempotent=false), the description adds the two-phase confirmation contract, the fact that it acts under the connected Gover account's API permissions, the credential-handling prohibition, and the resultadoId hand-off for large payloads. It stops short of saying what the preparation returns or whether it creates pending server-side state, but the added operational context is substantial.

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?

Short, front-loaded sentences with no padding; the phase constraint and the confirmation requirement come first and the secondary routing (resultadoId, payment data) comes last. Slightly list-like, but every sentence carries a distinct instruction.

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 high-complexity, deeply nested mutation-style tool with no output schema, the description covers the workflow, auth, and result handling well but leaves the parameter contract almost entirely unexplained. An agent can invoke it correctly at the process level but has no guidance on how to populate formData or the other identifiers.

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% across 8 top-level parameters with deep nesting, so the schema carries no field meaning. The description only says 'Os campos seguem o contrato da API' and that new payment data belongs in the Gover portal, which hints at the pagamento fields but explains no other parameter. With a very low coverage schema, the description needed to compensate and does not.

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 states a specific verb and resource ('Confirmar reserva e condicoes da solicitacao') and immediately clarifies the phase ('Prepara a acao, sem executa-la'), which resolves the tension between the tool name and its actual behavior. It also names the sibling that performs the execution (gover_confirmar_operacao), so an agent can separate the two phases. It loses a point only because the name 'confirmar_reserva' versus the 'preparar' behavior still requires the reader to reconcile two identities.

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?

Explicit sequencing: display parameters to the user, and only after explicit confirmation call gover_confirmar_operacao; for long outputs call gover_ler_resultado with the returned resultadoId. It also states a hard exclusion ('Nunca informe credenciais ou identidade de autenticacao como argumentos') and a constraint on where new payment data may be entered. The alternative tool and the condition that selects it are named outright.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds real context on top: the operation runs exclusively under the connected Gover account and its API permissions, credentials or authentication identity must never be passed as arguments, and new payment data must be entered only in the Gover portal. That privacy/auth/payment-handling guidance is exactly the kind of beyond-schema behavior worth disclosing.

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?

Sentences are short, front-loaded, and each carries an operational constraint or routing cue rather than narrative filler. The one weak line is "Os campos seguem o contrato da API," which is effectively boilerplate and earns no place, but overall the structure is efficient.

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 read-only tool whose annotations already cover the safety profile, the description adequately covers auth scope, credential handling, and result pagination. It is still incomplete for an 8-parameter tool with 0% schema coverage and no output schema, since it explains neither the inputs nor anything about the consulted acceptance payload.

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% across 8 parameters (termo, cidadeId, clientId, unidadeId, funcionarioId, solicitacaoId, tipoCentroDeCusto, finalidadeViagemId), and the description offers no meaning for any of them. The only nod is "Os campos seguem o contrato da API," which conveys no semantics, so the description fully fails to compensate for the coverage gap.

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 opening sentence restates the title nearly verbatim ("Consultar aceite de servicos adicionais"), so it names a verb and resource but adds almost no resolution beyond the name. It never distinguishes this from neighboring consult tools such as gover_consultar_solicitacao, gover_detalhar_solicitacao_completa, or gover_reemitir_adicionais, so an agent must guess which 'consulta' to pick.

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?

It gives one concrete routing rule — large results should be fetched via gover_ler_resultado with the returned resultadoId — plus the constraint that only the connected Gover account is used. However, there is no guidance on when this tool is the right choice versus the many other solicitation-consulting siblings, which is the more consequential selection decision.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read behavior is covered. The description adds useful context about authentication ('uses the Gover connected account... never provide credentials') and the result offset pattern, which goes beyond the annotations. It does not, however, detail pagination specifics or error 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 description is five short sentences and front-loads the core purpose. Most sentences add distinct value (auth, side-effect safety, result handling). However, the final sentence about payment data is only tangentially related and could be trimmed.

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 read-only query with no output schema, the description covers the safety profile and auth, and mentions result pagination. But with 11 undocumented parameters and no explanation of how to use them, the description is incomplete for an agent to invoke the tool correctly without trial and error.

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 there are 11 parameters, but the description only says 'fields follow the API contract' and mentions resultId for large results. It does not explain what any of the parameters mean (e.g., solicitacaoId, cidadeId, reservaId), leaving the agent with no semantic guidance. This is a significant gap given the low schema coverage.

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 clear verb+resource ('Consultar assentos selecionados' = query selected seats), which distinguishes it from siblings like gover_marcar_assentos (mark seats) and gover_consultar_mapa_assentos (seat map). However, it does not explicitly say what context it operates in (e.g., a specific reservation), so the differentiation is only partially explicit.

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 description notes it uses the Gover account and refers to the resultId pattern for large results, which implies usage context. But it never states when to use this tool versus alternatives like gover_consultar_mapa_assentos or gover_listar_passageiros_assentos, leaving the agent to infer.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real operational context on top: it runs exclusively under the connected Gover account and its API permissions, accepts no credential arguments, and large payloads must be fetched via gover_ler_resultado. That is meaningful behavioral guidance beyond the annotation set, though it omits permission errors or result-size thresholds.

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?

Short, front-loaded, and each sentence carries a distinct rule (account scoping, read-only, no credentials, large results, payment data). The closing note about new payment data is tangential to a read tool but still a useful boundary.

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 7-parameter query tool with zero schema coverage and no output schema, the description addresses auth and result overflow but says nothing about what the cart contents look like or how the seven filters scope the result. An agent can call it, but cannot call it precisely.

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?

Seven filter parameters (termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, finalidadeViagemId) have 0% schema description coverage, and the description compensates only with 'Os campos seguem o contrato da API' — it explains no parameter's meaning, format, or interaction. This leaves the caller guessing at the semantics of every input.

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+resource ('Consultar carrinho de compras do usuario') and clarifies the read-only nature ('Nao altera registros de negocio'), which separates it from mutating siblings like gover_remover_item_carrinho or gover_tarifar_carrinho. It does not, however, distinguish itself from other read siblings such as gover_consultar_solicitacao or gover_consultar_hospedagem explicitly.

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?

Provides one routing rule: for lengthy results use gover_ler_resultado with the returned resultadoId. It also implies the tool operates only on the connected Gover account. But it never states when to consult the cart versus browsing solicitation tools, nor any prerequisites or exclusions beyond credential handling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful operational context beyond annotations: it uses exclusively the connected Gover account and permissions, never accepts credentials, does not alter business records, and directs extensive results to gover_ler_resultado. It does not disclose rate limits or error behavior, so a 4 is appropriate.

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 description is front-loaded with the core purpose and then adds operational constraints in separate sentences. It is reasonably concise, though 'Os campos seguem o contrato da API' is vague filler and the payment warning could be trimmed for a read-only consulting tool.

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?

Given the nested input object with zero schema descriptions and no output schema, the description should explain how to supply the required form fields and what kind of data is returned. It does not cover parameter meaning at all and gives no indication of the return shape, leaving critical gaps for an agent to call the tool correctly.

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 input is a nested 'form' object with three integer fields (opcaoId, clienteId, centroDeCustoId) that are entirely undocumented. The description only says 'Os campos seguem o contrato da API' and 'por ID', which adds almost no meaning for the other fields or the nested structure, so it fails to compensate for the coverage gap.

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 ('Consultar centro de custo por ID'), making it clear this is a lookup by identifier. It implicitly distinguishes from search tools by 'por ID', but does not explicitly name or compare against siblings like gover_pesquisar_centros_custo.

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?

Provides some usage context: for extensive results use gover_ler_resultado, and new payment data must be handled only in the Gover portal. However, it does not explicitly say when to use this tool versus the sibling search tools (gover_pesquisar_centros_custo) or when it is inappropriate beyond the payment caveat.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior. The description does add useful constraints: it uses only the connected Gover account and its API permissions, never accepts credentials/authentication identity as arguments, and does not alter business records. However, it omits rate limits, pagination specifics, or error behavior, so it adds moderate rather than rich context beyond annotations.

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?

Short, front-loaded, and every sentence carries some instruction (account scope, no credentials, result handling, payment data). However, the opening is a redundant restatement of the title and the sentences are loosely organized rather than tightly sequenced.

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?

Given a read-only, open-world, idempotent tool with seven params at 0% schema coverage, the description covers safety and output continuity but leaves parameter meaning unexplained. It is adequate for an agent that already knows the API field names, but incomplete for one that does not.

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 compensate for seven undocumented parameters (termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, finalidadeViagemId) – none are explained. The line 'Os campos seguem o contrato da API' is a non-explanation. The gap is significant given zero coverage.

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 restates the title verbatim ('Consultar condutores para locacao'), which is tautological rather than defining. It does not differentiate from siblings like gover_consultar_funcionario or gover_buscar_veiculos. An agent can infer it reads driver data for rentals, but the purpose is not enriched beyond the name.

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?

There is no explicit when-to-use guidance, no conditions for selecting this over other consultar tools, and no exclusions. The only routing hint is for lengthy results via gover_ler_resultado, which addresses output handling rather than tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds valuable context beyond annotations: it clarifies that it uses only the connected Gover account and its API permissions, does not alter business records, forbids passing credentials or authentication identity as arguments, and directs large results to gover_ler_resultado. That is more behavioral detail than the annotations supply.

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 description is front-loaded with the main purpose and then lists constraints in compact sentences. It is appropriately sized for the tool and each sentence adds a distinct point (scope, safety, auth, routing, data-entry rule). One sentence, 'Os campos seguem o contrato da API', is vague and does not earn its place, but overall it is efficient.

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 read-only retrieval tool with annotations detailing the safety profile, the description covers auth scope, mutation safety, and result-size routing. However, it lacks any explanation of the two parameters, does not describe what a 'contato de atendimento humano' result contains, and gives no pagination or error behavior. With no output schema and 0% parameter coverage, the description is adequate but incomplete for correct invocation.

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 compensate, but there are 2 parameters (clienteId and numeroSolicitacao) with no explanation in the description or schema. The description says 'Os campos seguem o contrato da API', which acknowledges the fields without explaining what they mean or when to provide them. Baseline is 3 when schema is rich, but here the schema is bare, so this is a gap; still, the description avoids misleading the user and provides one relevant constraint (do not pass credentials).

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+resource: 'Obter contato de atendimento humano da viagem' — retrieve a human support contact for a trip. That is clear and distinguishable from siblings like gover_obter_info_usuario or gover_consultar_minhas_viagens. It is not differentiated from potential lookalikes within the 90+ sibling list, but the purpose is unambiguous.

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 description implies this is used to get a human support contact when needed, but gives no explicit when-to-use or when-not-to-use guidance. It names one alternative for large results (gover_ler_resultado), which is a routing hint, but does not clarify when to prefer this tool over a generic contact or info tool. Usage is implied, not stated.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely new context: it runs exclusively under the connected Gover account and its API permissions, it warns never to pass credentials/auth identity as arguments, and it discloses that large results are truncated and must be fetched via gover_ler_resultado. The statement that it does not alter business records is redundant with the annotations.

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 sentence and the remaining sentences are short, discrete directives. One sentence ('Os campos seguem o contrato da API') is filler boilerplate, but overall the text is compact and scannable.

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, and the description does cover the critical post-call behavior (resultadoId hand-off for large results) plus auth constraints. Still, for a nested required object at 0% schema coverage it never explains how to build the form or which identifier to supply, leaving a real gap for correct invocation.

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 single required parameter is a nested object with three undocumented fields (opcaoId, clienteId, departamentoId). The description only says 'Os campos seguem o contrato da API', which adds no meaning about what any field is or which ID is expected, despite the title promising lookup 'por ID'.

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 states a specific verb (Consultar) plus resource (departamento) and scope (por ID), which distinguishes it from the list/search sibling gover_pesquisar_departamentos. It does not, however, explicitly name any sibling, so differentiation from gover_alterar_departamento or gover_consultar_unidade is left to inference.

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?

Two conditional directives are given: use gover_ler_resultado with the returned resultadoId for extensive results, and fill new payment data only on the Gover portal. However, nothing tells the agent when to pick this tool over gover_pesquisar_departamentos or where the departamentoId is supposed to come from.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds genuinely new context: it runs exclusively under the connected Gover account and its API permissions, never accepts credentials as arguments, and streams large results via resultadoId. 'Nao altera registros de negocio' is redundant with destructiveHint=false but harmless.

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?

Sentences are short and front-loaded, which is good. But the closing sentence about payment data (Dados de pagamento novos...) is unrelated to a read-only points-expiration query and reads as boilerplate, diluting focus.

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 7-parameter query with no output schema and zero parameter documentation, the description should explain what the filter fields select and what is returned. It covers safety and pagination reasonably but leaves the entire input contract unexplained, which is a major gap.

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 0% across 7 parameters, and the description's only nod to them is 'Os campos seguem o contrato da API', which conveys no meaning. Nothing explains termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, or finalidadeViagemId, leaving fully undocumented inputs for a search-style tool.

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 first sentence states a specific verb and resource ('Consultar expiracao dos pontos'), which is more precise than sibling gover_consultar_pontuacao (points balance vs. expiration). However, it largely restates the tool title and never names or contrasts with the closest sibling, so an agent must infer the boundary itself.

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?

It gives one explicit routing rule: for extensive results use gover_ler_resultado with the returned resultadoId, and it warns that new payment data belongs only in the portal. There is still no guidance on when to choose this over gover_consultar_pontuacao or what preconditions (permissions, account state) apply.

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

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

Annotations already declare readOnly, idempotent and non-destructive. The description adds genuine behavioral context beyond that: it operates under the connected Gover account and its API permissions, never accepts credentials/auth identity as arguments, and requires the gover_ler_resultado follow-up for large payloads. This is useful operational detail rather than restating the annotations.

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?

Purpose is correctly front-loaded in the first sentence, but the paragraph then mixes security boilerplate ('Nunca informe credenciais') with guidance that appears unrelated to a read-by-ID lookup ('Dados de pagamento novos devem ser preenchidos somente no portal Gover'). Some sentences do not clearly earn their place.

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 simple read tool whose annotations cover the safety profile, the account/permission note and the large-result routing are adequate. However, with a 0%-described nested schema and no output schema, the total failure to explain the form fields leaves an agent without enough to build the request correctly.

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 single nested 'form' object carries three undocumented fields (opcaoId, clienteId, funcionarioId). The description's only contribution is 'Os campos seguem o contrato da API', which defers meaning rather than explaining any field, so it fails to compensate for the coverage gap.

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 plus scope: 'Consultar funcionario por ID'. This is distinguishable from the search-oriented sibling gover_pesquisar_funcionarios, though the description never names that sibling to sharpen the contrast. Clear but without explicit sibling differentiation.

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 an explicit routing condition: 'Para resultados extensos, use gover_ler_resultado com o resultadoId retornado', naming the alternative and when to switch to it. It does not, however, say when to use this lookup versus gover_pesquisar_funcionarios, so no exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, and the description adds context beyond them: the operation runs under the connected Gover account and its API permissions, credentials must never be passed as arguments, and large results are paginated via resultadoId. 'Nao altera registros de negocio' partly restates destructiveHint=false, but the auth and pagination disclosures are genuinely additive.

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?

Purpose is front-loaded in the first clause, followed by usage and behavioral constraints in short sentences. Several sentences are boilerplate guardrails, but each carries a distinct instruction rather than filler, so the length is defensible.

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 no output schema, the description usefully explains how to retrieve large result sets (resultadoId + gover_ler_resultado), covers the auth model and a payment-data exclusion, and all parameters are optional. The main gap is the undocumented clienteId and lack of parameter-level detail for an API-contract-driven tool.

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 carries the full burden, yet it only paraphrases two parameters ('localizador ou data') from their names and says nothing about clienteId. 'Os campos seguem o contrato da API' is a non-answer, and no format or matching semantics (e.g. date-time shape, locator string format) are supplied.

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 opens with a specific verb+resource ('Consultar hospedagem') and names the two lookup keys (localizador or data), so the agent knows exactly what this retrieves. It does not explicitly distinguish itself from nearby siblings such as gover_consultar_minhas_viagens or gover_consultar_hoteis_ofertados, which keeps it out of 5 territory.

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?

It gives a conditional routing rule for large responses ('Para resultados extensos, use gover_ler_resultado com o resultadoId retornado') and a hard exclusion ('Dados de pagamento novos devem ser preenchidos somente no portal Gover'). It never states when to prefer this tool over other lodging/solicitation lookups, so the guidance is clear but not exhaustive.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so redundancy about 'nao altera registros' earns little. What the description adds is genuinely beyond the annotations: the resultadoId pagination handoff to gover_ler_resultado, the account/permission scoping, and the constraint that payment data is filled only in the Gover portal.

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?

Six short sentences with the purpose front-loaded and no paragraph bloat. The credential warning and payment-portal note are borderline boilerplate, but the resultadoId guidance earns its place and nothing is buried.

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 tool with a nested 8-parameter schema at 0% description coverage and no output schema, the description is thin on how to actually build the request. It covers auth, safety and large-result handling, but leaves the agent with no help constructing formData fields such as hotelId, quartos, or the hospedesAssociados array.

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 0% across 8 parameters (including the nested formData object), and the only parameter-related text is 'Os campos seguem o contrato da API', which explains nothing about hotelId, quartos, hospedesAssociados, or any other field. It defers rather than compensates.

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 states a specific verb (consultar) and resource scope (hospedes por quarto), which is clearer than a bare restatement of the title. It does not, however, differentiate itself from close siblings like gover_consultar_hospedagem or gover_pesquisar_passageiros, so an agent must still infer which query surface is appropriate.

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?

It gives one concrete routing rule — 'Para resultados extensos, use gover_ler_resultado com o resultadoId retornado' — which is a real alternative-tool pointer, plus auth constraints ('usa exclusivamente a conta Gover conectada'). But there is no when-to-use/when-not guidance against the many other consultar/pesquisar siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the bar is lower, yet the description adds real context: it operates only through the connected Gover account and its API permissions, credentials must never be passed as arguments, and large results are retrieved via gover_ler_resultado using resultadoId. The 'no altera registros' clause is redundant with readOnlyHint but the rest is additive.

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 and the overall length is moderate, but several sentences are boilerplate that repeats across sibling tools, and the 'Nao altera registros de negocio' statement duplicates what the annotations already guarantee.

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 9 parameters, 0% schema description coverage and no output schema, the definition carries a heavy burden that it only partly meets. Auth, security and large-result handling are covered, but the parameters an agent must populate and the shape of the hotel results are absent.

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% across 9 parameters, and the description says only 'Os campos seguem o contrato da API' — a generic statement that adds no meaning. Key inputs such as solicitacaoId, termo, cidadeId, servicoId and finalidadeViagemId are left entirely undocumented, so the description fails to compensate for the schema gap.

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 states a specific verb and resource ('Consultar hoteis ofertados na solicitacao'), clearly identifying a read of offered hotels tied to a request. However, it does not distinguish itself from close siblings like gover_consultar_itens_ofertados or gover_consultar_veiculos_ofertados, leaving an agent to infer the boundary.

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?

It gives one concrete routing instruction: for extensive results, use gover_ler_resultado with the returned resultadoId, which is genuinely useful. But it offers no guidance on when to choose this over gover_buscar_hoteis or the other *_ofertados tools, so usage is mostly implied.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that it does not change business records and never accepts credentials, which aligns with annotations but adds little beyond them. It doesn't explain rate limits or detailed output 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?

Front-loads the main purpose in the first sentence, then provides supplementary notes. The text is reasonably concise and avoids unnecessary repetition, though some sentences like the credential warning are somewhat boilerplate.

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?

Given the tool has 10 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It mentions pagination handling but doesn't explain return format or parameter details. It covers security and mutation behavior adequately but misses parameter semantics.

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 there are 10 parameters. The description only vaguely says 'fields follow the API contract', providing no meaning for parameters like tipo, termo, cidadeId, etc. This fails to compensate for the low schema coverage.

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+resource: consult items offered for a request. This distinguishes it from related siblings like gover_consultar_hoteis_ofertados and gover_consultar_veiculos_ofertados, which cover different item types. It lacks explicit disambiguation, but the resource is clear.

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 context: uses the connected Gover account and permissions. It provides some guidance on pagination via gover_ler_resultado, but does not explicitly state when to use this vs other consult tools. No when-not guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds context annotations cannot carry: it uses only the connected Gover account and its API permissions, it never mutates business records, credentials must never be passed as arguments, and new payment data must go through the Gover portal. These are meaningful scope and security constraints beyond 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?

Short numbered-style sentences, front-loaded with the purpose before the operational constraints and the pagination pointer. Each sentence carries a distinct rule; only the portal/payment note is somewhat tangential to invoking the tool.

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 no output schema it correctly points at the resultadoId handoff for large payloads, which covers the pagination story. However, with 0% schema coverage on the parameters and no guidance on mutual exclusivity of the lookup keys, an agent still cannot construct a fully informed call.

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% for three parameters (data, clienteId, localizador). The description partially compensates by naming 'localizador' and 'data' as the query keys, but it never explains clienteId, the expected date format, or whether the keys combine or are alternatives.

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 opening sentence names a specific verb (Consultar) and resource (locacao) plus the two lookup keys (localizador or data), so the agent knows exactly what operation this is. It is not explicitly differentiated from lookalike siblings such as gover_consultar_localizador_aereo or gover_consultar_solicitacao, which is the only thing keeping it 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?

It gives one real routing rule — for large results use gover_ler_resultado with the returned resultadoId — which is genuinely useful. But it says nothing about when to prefer this tool over gover_consultar_solicitacao, gover_buscar_solicitacao, or the aereo locator variant, leaving the main sibling choice to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: it runs exclusively under the connected Gover account and its API permissions, credentials/identity must never be passed as arguments, and large payloads are paginated out through gover_ler_resultado with a resultadoId. That truncation/continuation contract is information the annotations cannot convey.

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?

Five short sentences, purpose front-loaded, with no padding; each sentence carries a distinct instruction (auth scope, no mutation, no credentials, pagination handoff, payment-data exclusion). Slightly boilerplate in places but efficient.

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 an 8-parameter, nested-object query tool with zero schema descriptions and no output schema, the description leaves the agent without any guidance on how to populate the arguments or which field combination identifies a locator. The resultadoId pagination hint is helpful, but the core parameter-usage gap remains significant.

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% across 8 parameters (including a nested formData object), so the description must carry the burden and it does not. Saying 'Os campos seguem o contrato da API' defers to an external contract rather than explaining what termo, cidadeId, segmentoId, localizador, solicitacaoId and the other fields mean or which are needed.

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 states a specific verb and resource (retrieve information about the air locator/PNR) and is clearly a read query, distinguishing it from mutation siblings like gover_adicionar_voo_carrinho. It does not, however, differentiate itself from adjacent read tools such as gover_consultar_viagem_aerea or gover_consultar_solicitacao, which an agent could easily confuse it with.

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?

It gives real routing guidance: extensive results should be fetched via gover_ler_resultado using the returned resultadoId, and new payment data must be entered only in the Gover portal (i.e., not here). It stops short of stating explicit preconditions or naming the sibling read tools it competes with.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: it operates only under the connected Gover account and its API permissions, credentials must never be passed as arguments, and pagination goes through gover_ler_resultado. The 'no altera registros de negocio' clause merely duplicates readOnlyHint, holding it just below a 5.

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 sentence is front-loaded and the remaining sentences are short and functional, each carrying a distinct rule (auth, credentials, pagination, payment data). It is slightly padded by the redundant 'não altera registros' clause, but nothing is bloated.

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 an 11-parameter read tool with no output schema, the description covers auth behavior and pagination well enough, and annotations carry the safety profile. But it leaves the required identifiers and the overall return shape undocumented, so an agent cannot rely on it alone to invoke the tool correctly with non-obvious inputs.

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% across 11 parameters, including three required ones (reservaId, segmentoId, solicitacaoId) that are never explained. The only parameter-related statement, 'Os campos seguem o contrato da API', is a non-answer that adds no meaning. With low coverage the description is expected to compensate, and it does not.

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 first sentence 'Consultar mapa de assentos' states a verb+resource but is a verbatim restatement of the title, adding no distinguishing information. The crowded seat-related sibling set (gover_marcar_assentos, gover_consultar_assentos_selecionados, gover_iniciar_selecao_assentos, gover_listar_passageiros_assentos) is never addressed, so an agent gets only a vague sense of what this returns versus those tools.

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?

It gives one concrete routing rule: for extensive results, call gover_ler_resultado with the returned resultadoId. That is genuine usage guidance. However, it never explains when to prefer this over the adjacent seat tools (marcar/consultar_assentos_selecionados), so the selection context is only implied.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: authentication is exclusively via the connected Gover account, credentials must not be passed as arguments, and large results are handled through gover_ler_resultado with a resultadoId.

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 and the text is not excessively long, but several sentences are boilerplate or tangential, such as the payment-data note that is unrelated to a read-only trip query. The API contract sentence adds little and the overall structure could be tighter.

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?

Given the absence of an output schema and full annotation coverage, the description covers auth and result-pagination handling reasonably well. However, it leaves the three optional parameters largely unexplained and does not describe the normal return shape, so an agent still lacks information needed for confident invocation.

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 compensate. It mentions filtering by 'solicitacao ou data', which loosely maps to two of the three parameters, but it never mentions 'clienteId' and gives no format, nullability, or combination semantics for any parameter, leaving the schema undocumented.

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 first sentence gives a specific verb ('Consultar') and resource ('viagens do passageiro logado') with scope qualifiers ('por solicitacao ou data'). It distinguishes the tool from generic consultation siblings through the 'passageiro logado' restriction, but it does not explicitly name an alternative tool for cases where a different query is needed.

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 implied by the stated purpose and filter options. The description provides one explicit fallback ('Para resultados extensos, use gover_ler_resultado...'), but lacks guidance on when to choose this tool over other consultation siblings or when not to use it.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description goes further by disclosing auth constraints ('Nunca informe credenciais ou identidade de autenticacao' as arguments) and that new payment data must be entered only on the Gover portal. These add real operational context beyond the structured hints, though it restates 'nao altera registros' which overlaps the readOnly hint.

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?

Reasonably front-loaded, with the key capability stated first and routing/security notes after. However, 'Os campos seguem o contrato da API' is filler that adds no information, weakening an otherwise tight description.

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 should carry return-value context; it partially does by mentioning the resultadoId and the gover_ler_resultado follow-up for large result sets. It remains thin on what the panel returns and which filters matter, leaving the definition only adequate for a 7-param, undocumented-schema tool.

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?

Seven optional params with 0% schema coverage, and the description compensates only with the vague 'Os campos seguem o contrato da API'. It never explains what termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, or finalidadeViagemId filter, so the agent gets no semantic grounding for the filters it must supply.

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 ('Consultar') and resource ('painel do usuario autenticado'), with the scope qualification that it uses only the connected Gover account. It is clear what the tool does, though it does not articulate how it differs from the many other 'consultar_*' siblings.

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?

It routes the agent to gover_ler_resultado for extensive results ('Para resultados extensos, use gover_ler_resultado com o resultadoId retornado'), which is a genuine usage hint. However, it never states when this panel consult is preferred over alternatives, nor prerequisites beyond the implied connected account.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuine operational context: it runs only under the connected Gover account and its API permissions, and it explicitly forbids passing credentials or auth identity as arguments — a real constraint not in the annotations.

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?

Purpose is front-loaded and the resultadoId guidance is useful, but the trailing sentence about payment data in the Gover portal is tangential to invoking this read tool, and the body is a run of loosely related sentences rather than a tight structure.

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 7-parameter, no-output-schema tool the description does help by explaining the resultadoId continuation path, but it leaves every parameter's meaning undefined and gives no hint of what the returned score payload contains. Adequate at the boundary, with clear gaps.

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% across 7 parameters (termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, finalidadeViagemId), and the description only says 'Os campos seguem o contrato da API', which conveys no meaning. The obligation to compensate for the coverage gap is unmet.

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 ('Consultar pontuacao detalhada do usuario'), so the agent knows it reads a points/score entity. It does not differentiate from near-siblings like gover_consultar_expiracao_pontos or gover_obter_info_usuario, so it falls 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?

Gives one concrete routing rule: for extensive results, call gover_ler_resultado with the returned resultadoId. However it never says when to choose this tool over gover_consultar_expiracao_pontos or other consultar_* siblings, leaving the main selection decision to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's job is lighter. It still adds valuable context: the tool gathers internal evidence, produces a simple-language answer, and explicitly forbids showing code. This goes beyond annotation metadata and helps the agent set correct expectations.

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 sentences with no filler; the core purpose is front-loaded, and the 'never show code' rule is a valuable constraint for the response. It could be slightly tighter, but it remains appropriately sized and structured.

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 read-only Q&A tool with an output schema and fully documented parameters, the description covers the essential context: purpose, response style, and availability without an account. It doesn't define 'evidências internas' in depth, but that level of detail is not required to invoke the tool correctly.

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 100%, and both 'pergunta' and 'maxEvidencias' already have clear descriptions. The tool description adds only a semantic hint that 'pergunta' concerns system behavior; it does not expand on 'maxEvidencias'. Baseline 3 is appropriate given full schema coverage.

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 uses a specific verb ('Recebe uma dúvida'), defines the resource ('funcionamento do Gover'), and states the deliverable: explain the business rule in simple language, never showing code. This clearly differentiates it from data-query siblings like gover_executar_consulta and gover_explorar_estrutura.

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?

It clearly specifies when to use the tool: when there is a doubt about how Gover works and a plain-language explanation is needed. It also adds a useful condition ('Disponível sem conexão de conta neste ambiente'). However, it does not explicitly name alternatives or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces safety with 'Nao altera registros de negocio' and adds a relevant security constraint about credentials/identity. This is helpful added context, but it does not disclose pagination behavior, result size limits, or what auth/permission failures look like. With annotations covering the safety profile, this is adequate but not rich.

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 description is compact and front-loads the core purpose, followed by safety, routing, and security notes in short sentences. It is efficient overall, though the opening sentence duplicates the title and the API-contract sentence is low value.

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 an 11-parameter read tool with no output schema and 0% schema coverage, the description is minimal but covers safety (non-destructive, auth-bound) and a fallback path to gover_ler_resultado. It still leaves the agent without any explanation of parameter meanings or expected result shape, so it is only partially 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 description coverage is 0% across 11 parameters, so the description carries the full burden of explaining them. It only says 'Os campos seguem o contrato da API', which is uninformative and defers to an external contract, leaving names like 'termo', 'tipoOpcao', 'isRoundTrip', and 'tipoCentroDeCusto' undocumented for an agent.

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 restates the title almost verbatim ('Consultar resultados da pesquisa aerea'), which is essentially a tautology relative to the name/title. It does not specify what kind of results (flight options, prices, availability) or how it differs from siblings like gover_buscar_voos, gover_consultar_viagem_aerea, or gover_ler_resultado beyond a brief mention of the latter for large payloads.

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?

It provides one conditional routing rule: 'Para resultados extensos, use gover_ler_resultado com o resultadoId retornado', which is a useful pointer to a sibling. However, it offers no guidance on when to prefer this tool over gover_buscar_voos, gover_cotar_voos, or gover_iniciar_pesquisa_aerea, leaving selection ambiguous.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, but the description adds meaningful context beyond them: it confirms 'Nao altera registros de negocio', warns never to pass credentials as arguments, and explains the pagination handoff to gover_ler_resultado for large results. These are useful operational details that annotations alone do not provide.

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 sentence, and the remaining sentences cover auth, safety, pagination, and a payment rule. Most sentences earn their place, though 'Os campos seguem o contrato da API' is filler and could be dropped.

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 simple read-only tool with only two parameters and no output schema, the description covers authentication context, non-mutation, pagination, and a domain restriction. The main missing piece is differentiation from sibling lookup tools like gover_detalhar_solicitacao_completa, but the core callable information is largely present.

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 compensate. It names solicitacaoId in the first sentence, implying it identifies the request, but it never explains the optional numeroInterno parameter, and the phrase 'Os campos seguem o contrato da API' adds no usable semantic detail. One of two parameters is functionally undocumented.

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 states a clear verb and resource ('Consultar detalhes por solicitacaoId'), so an agent knows it fetches details for a given request ID. However, it does not distinguish this tool from several close siblings such as gover_detalhar_solicitacao_completa, gover_buscar_solicitacao, or gover_acompanhar_solicitacao, leaving the agent to infer which 'consultar' variant to pick.

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 description gives one explicit routing rule ('Para resultados extensos, use gover_ler_resultado com o resultadoId retornado') and one domain restriction (payment data must be entered only in the Gover portal). It does not say when to use this tool versus the many alternative solicitation lookup tools, so usage is only partially guided.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds real behavioral context beyond them: it discloses the account/permission scoping, forbids passing credentials, and reveals a pagination/truncation workflow (resultadoId -> gover_ler_resultado).

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?

Purpose is front-loaded, but the body is a grab-bag of boilerplate (credential warnings, payment data portal note) that dilutes the operative content. Several sentences are generic policy statements rather than task-specific guidance.

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?

Annotations cover the safety profile and the description covers the pagination workflow, but with no output schema and 7 fully undocumented parameters the agent still lacks enough to call it correctly or interpret the status response.

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?

All 7 parameters have 0% schema description coverage, and the description offers only the vacuous statement that fields follow the API contract. None of termo, cidadeId, clientId, unidadeId, funcionarioId, tipoCentroDeCusto, or finalidadeViagemId is explained, leaving the caller with no semantic guidance.

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 states a specific verb+resource: checking the status of a price comparison. It is clearly distinguishable from adjacent siblings like gover_solicitar_comparativo_precos (request) and gover_ler_resultado (read results), though it does not explicitly name them in the purpose statement.

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?

It gives one conditional routing rule: for extensive results, use gover_ler_resultado with the returned resultadoId. However, it never states when to call this tool versus requesting a new comparison or saving one, so the broader usage context is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, but the description adds auth context ('usa exclusivamente a conta Gover conectada'), a security warning against passing credentials, and a large-result handoff pattern via resultadoId. It also notes that new payment data must be entered only in the Gover portal, which is useful domain policy despite being tangential.

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 sentence, but the description then stacks several policy statements, including a payment-data note that seems copied from a broader guideline. Some material is wasted or redundant with annotations, though the overall length is not extreme.

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 nested-object, ID-based lookup with no output schema, the description omits the critical mapping of nested fields and does not explain return values beyond a large-result handoff. It compensates somewhat with auth and safety context, but an agent still lacks enough to invoke the tool confidently.

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 single nested 'form' parameter contains opcaoId, clienteId, and unidadeId with no field-level documentation. The description only says 'Os campos seguem o contrato da API', which gives the agent no way to know which nested field is required or what each represents.

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 'Consultar' plus resource 'unidade' and qualifier 'por ID', which distinguishes it from sibling write tools like gover_alterar_unidade and search tools like gover_pesquisar_unidades. It does not explicitly name a sibling alternative, but the ID lookup scope is clear.

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?

No explicit guidance on when to choose this tool over gover_pesquisar_unidades or other consultar tools. The only alternative mentioned is gover_ler_resultado for handling large results, which is a follow-up step rather than a selection criterion.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds real behavioral context beyond them: it operates exclusively under the connected Gover account and its API permissions, does not modify business records, and requires that credentials never be passed as arguments. The resultadoId/pagination handoff to gover_ler_resultado is also a meaningful trait.

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 description is front-loaded with the purpose and each subsequent sentence carries a distinct rule (auth scoping, no writes, no credential args, pagination, payment-data boundary). The sentence "Os campos seguem o contrato da API" is filler that adds no information, slightly diluting an otherwise tight structure.

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 read-only tool with no output schema, the description covers auth and the large-result path adequately, but with nine parameters at 0% schema coverage it leaves an agent without any guidance on what the filters mean. It is adequate on operations and weak on inputs.

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% for nine parameters, and the description compensates with only "Os campos seguem o contrato da API," which defers rather than explains. The sole required parameter (solicitacaoId) is hinted at by "na solicitacao," but the eight optional filters (termo, cidadeId, clientId, servicoId, unidadeId, funcionarioId, tipoCentroDeCusto, finalidadeViagemId) remain undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.