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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true; the description adds the allowed input domain and points to result links. It does not disclose what happens on invalid input, which browser is used, or whether the call blocks, so it 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?

Two sentences, front-loaded with the verb and accepted resources, then the usage rule. No redundant or filler content.

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 one-parameter tool with annotations covering safety, the description supplies purpose, accepted input domain, and usage context. It omits error behavior, but that is a minor gap for a simple browser-opening action.

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 only parameter `url` is undocumented in the schema. The description compensates by specifying which URL types are accepted (SUAP link, file:// PDF, DOI) and where to source them, though it doesn't give exact syntax for a DOI.

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 ('Abre') and resource ('no navegador') and enumerates accepted URL types (SUAP link, file:// PDF, DOI). The scope 'Só esses' clearly bounds the tool, letting an agent distinguish it from sibling actions like salvar_no_suap.

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: 'quando o docente pedir para ver algo' and source: 'use os links que vieram nos resultados (`links`)'. It also gives a when-not by restricting to only those URL types, but names no alternative sibling 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 only declare readOnlyHint and openWorldHint, so the description usefully adds the timing contract (default 10, max 25 seconds, may return earlier on stage change) and the required UI behavior of surfacing `progresso` each call. This is meaningful behavioral 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?

Two dense sentences that front-load the action (monitor) followed by the timing and UI instructions; there is little waste. Slightly terse given the tool's polling nature, but well-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 polling tool with annotations covering the safety profile and no output schema, the description supplies the key missing pieces: timing bounds, early-return behavior, and the directive to display `progresso` and re-call. Adequate to invoke 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 compensate. It does explain `segundos` semantics (default 10, max 25) beyond the schema's bare default, but says nothing about `tarefa_id` (the required param), leaving half the parameters undocumented in both places.

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?

Names a specific verb and resource ('Acompanha uma tarefa em segundo plano') and gives concrete examples (login, coleta), so an agent can tell it is a background-task poller. It does not explicitly contrast itself with siblings, 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?

Provides clear operational context: it returns within `segundos` or earlier on stage change, and instructs the agent to show the `progresso` line and 'chame de novo' (call again), defining the polling loop. No explicit when-not or named alternative, but the usage pattern is spelled out.

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, so the mutation profile is covered. The description adds non-obvious behavior beyond that: the post-update requirement to restart the AI app or reconnect Expeditto before the new version takes effect, plus the need for explicit confirmation before setting confirmado=true.

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, no waste: purpose first, then the confirmation constraint, then the post-condition. Everything is front-loaded and each clause earns its 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 single-parameter destructive action with annotations covering safety and no output schema, the description covers purpose, confirmation gating, and the required restart. Minor gaps remain (e.g. failure behavior, that the check-only path is a sibling), but nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the semantics of 'confirmado', and it does explain the intent: set confirmado=true only when the docente requests it. It does not clarify what confirmado=false (the default) does, but the safety-critical meaning of the flag is conveyed.

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 ('Atualiza o Expeditto para a versão mais nova'), so an agent knows this performs the upgrade, not just a check. It does not name the related sibling 'verificar_atualizacao', so sibling differentiation relies on the audience already knowing the update-check tool exists.

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 constrains when to call: 'Só chame com confirmado=true se o docente pedir', i.e. only on explicit user request. This is a genuine when-to-use guard. It stops short of pointing to 'verificar_atualizacao' as the tool for merely checking, leaving that routing 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 cover read-only and open-world. The description adds real behavioral context beyond them: authentication happens via the CLI ('expeditto gmail-login'), and the return is a numbered candidate list rather than a direct write. This is genuinely useful for an agent.

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 dense sentences, zero waste, with the scoping constraint and the auth prerequisite front-loaded before the return behavior. Nothing extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so the description's note that it returns numbered candidates is necessary and helpful. However it leaves the one parameter undocumented and gives no hint about result volume, filtering, or failure modes if no authorized account exists.

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?

One required parameter ('semestre') with 0% schema description coverage, and the description never mentions it or its expected format. With no schema help and no description compensation, the agent gets no semantic guidance for the sole 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 ('busca atas no Gmail') and scopes it as a BACKUP path for hosts without email integration. It doesn't name the sibling (registrar_atas_gmail) explicitly, but the routing condition makes the distinction inferable.

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 states when to use it (backup for hosts WITHOUT email integration) and what follows (the professor selects which candidates to register). No explicit exclusions against named alternatives, but the triggering context 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 this as a non-read-only, idempotent, non-destructive mutation. The description adds useful context by specifying that it moves a loose file from the input folder to a teacher-specified topic, but it does not cover permissions, overwrite behavior, or side effects.

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?

A single sentence, front-loaded with the action and resource. No wasted words, though it is too terse to be fully informative for a 3-parameter 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?

For a mutating 3-parameter tool with no output schema and 0% schema descriptions, the description is too sparse. It omits the semestre parameter entirely, provides no usage conditions, and adds little behavioral detail beyond what annotations already imply.

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 3 required parameters. The description references arquivo and tópico loosely but omits semestre entirely and provides no format, constraints, or meaning for any parameter beyond natural-language names.

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 (Move) and resource (a loose file from the input folder to the teacher-specified topic). The action is clear enough to distinguish it from sibling tools like pasta_entrada or contexto_topico, though it does not explicitly name alternatives.

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 guidance on when to use this tool versus alternatives, no preconditions, and no exclusions. Usage is only implied from the operation itself, leaving the agent to infer the correct context.

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=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds important behavioral context beyond annotations: it runs in the background (2–8 minutes), returns a `tarefa_id`, and should be tracked with `aguardar_tarefa` while showing a progress bar to the instructor. It does not cover permissions or repeat-run semantics, but it is strong given the annotation baseline.

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 wasted words. The core action and duration are front-loaded, followed immediately by the return value and follow-up instruction. Highly 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?

With no output schema, the description correctly discloses the returned `tarefa_id` and how to track it. It covers the asynchronous nature and expected duration. Minor gaps remain, such as what happens on invalid semester input or authentication requirements, but annotations partially cover the latter.

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 specifies the expected format for the single required parameter `semestre` as '(AAAA.P)', which is essential syntax not present in the schema. It does not clarify optionality or validation, but for a one-parameter tool this is useful compensation.

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: 'Coleta os comprovantes do semestre (AAAA.P) no SUAP'. It also names the companion tool for follow-up (`aguardar_tarefa`), making it easy to distinguish from siblings like `listar_semestres` or `resumo_semestre`.

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: collect semester receipts, then monitor with `aguardar_tarefa`. There is no explicit guidance on when to prefer this over other semester-related tools, nor any exclusions. The follow-up instruction is helpful but not a full when-to-use statement.

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 write behavior (readOnlyHint=false), idempotency and non-destructiveness, and openWorldHint covers the external lookups. The description adds the concrete external sources (Crossref, OpenAlex), which is useful, but it frames the action as 'sugerir' (suggest) and never states what actually gets written to the record, leaving a gap for a mutating tool.

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 dense sentences with no filler; the fetched fields and the goal are front-loaded, and the usage condition follows. Efficient, though the parenthetical field list is slightly compressed.

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 single-parameter, externally-sourced mutation tool with no output schema, the description covers purpose, sources, and when to invoke it. What is missing is what the tool writes back and the meaning/format of the 'semestre' input, but the core is largely 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% for the single required 'semestre' parameter, so the description carries the burden and does not define its format or which semester it scopes to. The word 'semestre' appears in the description, giving an indirect hint, but no explicit parameter semantics are provided.

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 (busca), the exact data fetched (data, tipo, veículo, DOI) and the external sources (Crossref, OpenAlex), plus the goal (sugerir o semestre). It clearly distinguishes itself from the normal collection flow ('A coleta já faz isso'), though it references that flow generically rather than by sibling 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?

Explicitly scopes usage: 'use em coletas antigas ou quando os itens vierem sem data', and implicitly tells the agent not to use it during normal collection. Clear when-to-use conditions with a soft exclusion, but no named alternative 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the downstream intent (feeding the Relato) and discloses nothing about return content, scope limits, or whether data beyond the semester/topic is touched.

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, purpose front-loaded before the enumerated topic values. No waste, though the brevity edges toward under-specification rather than genuine conciseness.

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 two required params, no output schema, and 0% schema coverage, the description leaves the return shape, semester format, and relationship to downstream report tools unexplained. It is too thin 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?

Schema coverage is 0%, so the schema documents neither parameter. The description compensates meaningfully for 'topico' by enumerating its allowed values (apoio_ensino, ... gestao), which the schema lacks as an enum, but it says nothing about 'semestre' or its expected format.

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 phrase 'Fatos de um tópico para redigir o Relato' conveys that it fetches facts for a given topic to write a report, which is a recognizable resource. However the verb is only implied (a noun phrase), and nothing distinguishes it from siblings like resumo_semestre or coletar_semestre that also deal with semester data.

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 purpose hints at when it is used (writing the Relato), but there is no explicit when-to-use, no when-not-to-use, and no named alternative. The listed topic values help the caller pick a topic but do not route between sibling 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 readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful behavioral context by specifying the returned explanation content and links (SUAP, comprovante, DOI), which helps an agent know what calling it produces.

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, front-loaded with the core explanation and ending with the usage condition. Every clause earns its place and there is no redundant framing.

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 two-parameter tool with no output schema, the description explains the return content and usage context well. However, it leaves the required parameters entirely unexplained at 0% schema coverage, which is a meaningful completeness 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?

The description never mentions the two required parameters, semestre and numero, and schema description coverage is 0%. It only implies that some pendência is being identified, leaving parameter meaning and format 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 (Explica), resource (UMA pendência), and scope (one item), and enumerates the explanatory content. It does not explicitly differentiate itself from siblings like resolver_pendencia, so the sibling-differentiation criterion for a 5 is unmet.

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 final sentence gives a clear use condition: when the teacher has a doubt about an item. It does not state when not to use the tool or name alternative siblings, but the intended context is explicit.

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 and openWorldHint=true, so the safety profile is known; the description adds real value by disclosing the exact dimensions probed (version, data folder, browser, SUAP session, profile, AI apps, e-mail). It also reveals an output trait – each failing item carries a 'como_resolver' field – which matters because no output schema exists. It does not say whether the check is slow, needs login, or probes network services.

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, front-loaded with the main verb and the enumerated scope, followed by a genuinely useful note about 'como_resolver'. No filler or repetition; the enumeration is long but each item earns its place by defining the check's coverage.

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, zero-required-parameter diagnostic with no output schema, the description is close to sufficient: it tells the agent what is inspected and that problems ship with resolution hints. Minor gaps remain regarding runtime duration, whether it requires prior login, and the meaning of the lone toggle parameter.

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?

The single parameter 'verificar_suap' has no description in the schema (0% coverage), and the description never mentions it, so the agent must guess what toggling it off does (presumably skipping the SUAP session probe). The description does explain that SUAP session is one of the checked items, but that only vaguely implies the parameter's role.

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 ('Verifica se o Expeditto está pronto') and enumerates exactly what is checked (versão, pasta de dados, navegador, sessão no SUAP, perfil, apps de IA, e-mail), which makes its scope unambiguous. It does not explicitly distinguish itself from the nearby sibling 'verificar_atualizacao', whose 'versão' check partially overlaps, 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?

Usage is only implied: a readiness check is naturally run before other operations or when something is broken, and the mention of 'como_resolver quando há problema' hints at troubleshooting. There is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings (login, verificar_atualizacao, atualizar_expeditto).

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 disclose write (readOnlyHint=false), idempotent=true, non-destructive, closed-world, so the safety profile is covered. The description adds the data source but says nothing about whether the result is persisted, returned as text, or requires a subsequent salvar_no_suap call — a gap given the tool sits in a pipeline with save-oriented siblings.

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?

A single front-loaded sentence with no filler; it states action, artifact and source efficiently. It is arguably too terse for the pipeline role it plays, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with an undocumented required parameter, no output schema and no annotations describing results, the description leaves key questions open: what exactly is produced, where it goes, and what the semester string must look like. It is not sufficient 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?

The single parameter 'semestre' has 0% schema description coverage and is never mentioned in the description, so the agent gets no format guidance (e.g., '2024.1' vs '2024-1') for its only required input. This is the one place the description should have compensated and did 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?

Names a specific action ('Monta') and a specific artifact ('Alterações de Atividades') plus its input source ('pendências justificadas pelo docente'), so the agent can tell what is produced. It does not, however, differentiate itself from near-neighbors such as resolver_pendencia, previa_preenchimento or montar_anexos.

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 phrase 'a partir das pendências justificadas pelo docente' implies a precondition (justified pending items must exist) but never states when to call this vs. the sibling pendência/ata tools, nor what the caller must do first. Usage is only inferable.

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=false and idempotentHint=true, so the safety profile is covered. The description adds a real behavioral guarantee beyond that: existing reviewed texts are preserved unless explicitly requested. It still omits what a 'rascunho' contains, whether it runs synchronously, and what the result looks like.

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?

A single efficient sentence with the core action front-loaded and the non-destructive guarantee as a parenthetical clause. No wasted words, though the brevity comes at the cost of missing parameter detail.

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 mutation tool with no output schema, the description conveys the essential effect and the preservation guarantee. However, with 0% parameter documentation it leaves the agent guessing about the 'semestre' format and the exact trigger for 'sobrescrever', which is the main 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 0% for two parameters. The description never names 'semestre' nor its expected format, and only indirectly gestures at 'sobrescrever' via 'salvo se pedido'. With no schema documentation, the description should have compensated but largely 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 ('Gera') and resource ('rascunhos automáticos dos Relatos'), so the agent knows this produces draft report content. It does not name or contrast itself with any sibling (e.g. gerar_alteracoes, previa_preenchimento), so sibling differentiation 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?

The phrase 'não sobrescreve textos já revisados, salvo se pedido' implies the default execution context and hints at when to set the override, but it never states when to prefer this tool over siblings like gerar_alteracoes or previa_preenchimento. Usage is implied rather than explicit.

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 and openWorldHint=false, and an output schema exists, so the safety and return-value burdens are largely carried by structured fields. The description adds that the tool serves up guide content by section, which is modest context beyond the annotations but nothing about pagination or content depth.

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, front-loaded with what the tool is before the when-to-read instruction. The section list is dense but earns its place by revealing the tool's scope. No wasted framing.

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 an output schema covering return values and read-only annotations covering safety, the description only needs to convey purpose and invocation, which it does. The lone gap is that the `assunto` value space is implied rather than stated, which matters for a 0%-coverage parameter.

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% on the single `assunto` parameter, so the description must compensate. It partially does by naming section values (fluxo, topicos, pendencias, relatos, lattes, regras) and hinting that `fluxo` is a valid value, but it never explains the 'indice' default nor states that these section names are the accepted inputs.

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

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (a guide for the Expeditto assistant) and enumerates its coverage areas — fluxo, topicos, pendencias, relatos, lattes, regras — so an agent understands this is a reference/help tool rather than an action tool, distinguishing it from action siblings like gerar_alteracoes or salvar_no_suap. It stops short of explaining what 'Expeditto' is, but the enumerated sections make the purpose concrete.

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 trigger: read `fluxo` at the start of a conversation about the RIT, and the specific subject when needed. That is a clear usage context. It does not name alternatives or when-not to use it (e.g., versus contexto_topico), so it falls short of a 5.

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 annotations already establish that this is a read-only, open-world operation. The description adds domain context about what data is returned (semester, PIT/RIT state, SUAP link), but does not disclose additional behavioral traits such as auth requirements, rate limits, or side effects. With annotations covering the safety profile, this is adequate but 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?

It is a single compact sentence with no filler. It is front-loaded with the resource, though as a noun phrase it lacks the structural clarity of an explicit verb-led statement.

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 zero-parameter list tool with an output schema and read-only annotations, the description gives enough context to understand what will be returned. It does not need to explain return values because an output schema exists. The only notable gap is the absence of routing guidance versus sibling tools.

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?

The tool takes zero parameters, so the schema does not need parameter documentation. The description correctly does not invent any parameter semantics, and the baseline for zero-parameter tools is 4.

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

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (semesters) and what each record contains (PIT/RIT status and SUAP link), but does not use an explicit action verb like 'list'. It distinguishes itself from siblings only by implication; an agent can infer it returns a list, but the purpose is not stated as sharply as it could be.

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 guidance on when to use this tool versus alternatives such as resumo_semestre or coletar_semestre. No context, exclusions, or prerequisites are provided.

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 cover the safety/idempotency profile, and the description adds genuinely non-obvious behavior: the window auto-closes, login requires human interaction (CAPTCHA/Gov.br), and the call is asynchronous, returning a `tarefa_id` rather than the login result. That async, human-in-the-loop nature is exactly the kind of context 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?

Two tight sentences, front-loaded with the action and the auth constraint, then the return value and follow-up. 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?

With no output schema, the description carries the return contract (a `tarefa_id` to be tracked by `aguardar_tarefa`) and the interaction requirement, which is sufficient for an agent to call and sequence 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?

Zero parameters, so the baseline is 4 per the rubric. The description correctly does not invent parameter semantics and instead documents the return value, which is the relevant contract for a no-arg call.

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 (opens a SUAP window for the teacher's login) and names the concrete auth mechanism (CAPTCHA/Gov.br). It is clearly distinguishable from siblings like abrir_no_navegador because it is scoped to the SUAP login flow.

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 tells the agent what to do next (track with `aguardar_tarefa`, tell the teacher to watch the window), which implies when it fits in a workflow. It does not state an explicit when-not or name a competing alternative, so it stops short of a 5.

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 the operation is non-readonly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful artifact context (what the PDF contains and the 10 MB limit) but says nothing about where files are written, return values, or required auth.

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?

A single front-loaded sentence with the verb first and parenthetical details that all earn their place; 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 simple one-parameter tool with no output schema, the description documents the generated artifact well enough to understand purpose, but it omits parameter semantics and usage conditions, leaving the agent to guess what value to pass and when to invoke it.

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?

One parameter ('semestre') has 0% schema description coverage, yet the description never mentions it, its format, or which semester's topics are processed. The parameter's meaning must be inferred from its Portuguese name alone.

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 ('Gera') and artifact ('PDF de anexo') scoped to each topic, with composition details (capa + índice + comprovantes) and a size cap. It is distinct from sibling generators like gerar_rascunhos, though it does not name alternatives.

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 when-to-use instruction, no prerequisites, and no indication of when to prefer this over siblings such as gerar_rascunhos or salvar_no_suap. The purpose is implied but the agent receives no routing 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is partly covered, but the description adds nothing about what is returned, whether a folder must already exist, or how the 'E8' reference affects behavior. The phrasing ('where the teacher places...') even hints at a write/placement concern that the readOnly annotation does not clarify away.

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?

It is a single short sentence with no padding, which is good, but brevity here comes at the cost of under-specification rather than through efficient information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 0% parameter coverage, no output schema, and an ambiguous operation, the description is not sufficient for an agent to invoke this tool correctly. At minimum it should say what the call returns and what 'semestre' expects.

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 parameter 'semestre', and the description never mentions it or explains its format (e.g., '2024.1'). The description provides zero semantic help for the only parameter.

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 never states a verb or operation; it describes a location/convention ('onde o docente coloca comprovantes'), leaving the agent unsure whether the tool returns a path, lists files, or creates a folder. The content-type and per-topic-subfolder detail hints at scope but does not tell the agent what the tool actually does.

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 indication of when to call this tool versus siblings such as 'montar_anexos', 'classificar_entrada', or 'salvar_texto'. No prerequisites, no alternatives, no exclusions.

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 and openWorldHint=true, so the safety profile is covered. The description usefully adds that this is a diagnostic/router that reports semester state and recommends the next tool, but discloses nothing about output shape or what the listed RITs contain.

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?

Three sentences, tightly front-loaded with the entry-point role first, then its diagnostic function, then the no-argument fallback. Every sentence earns its 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 routing tool with no output schema but present annotations, the description is largely sufficient: it explains the mode of operation and the fallback. The only gap is the unexplained 'seguir_sem_decidir' parameter.

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 parameter burden. It explains 'semestre' as the semester in AAAA.P format and its absence behavior, which is helpful, but the second parameter 'seguir_sem_decidir' is never mentioned, leaving it 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 gives a specific role: 'PONTO DE PARTIDA' (entry point) that reports which step the semester is in and which tool to call next. This clearly distinguishes it from sibling action tools (gerar_alteracoes, salvar_no_suap, etc.) as the orchestration/routing entry point for RIT work.

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 states the trigger condition explicitly ('qualquer pedido sobre o RIT') and describes the behavior when no semester is supplied (lists RITs to choose). It does not name the specific sibling tools it routes to, but the when-to-use context 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that this is a preview of what will be sent (texts and attachments), which clarifies the non-destructive nature and content scope, but it does not describe return format, authentication, or rate limits beyond that.

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 a single, front-loaded sentence with no waste. It efficiently combines purpose and a usage directive, though the lack of any structural separation makes it slightly terse for a tool with an undocumented parameter.

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 one required parameter and no output schema, the description fails to document the parameter's meaning and does not describe what the preview returns or how it is presented. While the read-only annotation reduces the need for safety details, the parameter omission is a significant gap in an otherwise minimal description.

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 parameter 'semestre'. The description does not mention this parameter at all, nor does it explain what semester information is needed or how it affects the preview. An agent must guess the parameter's meaning from its name alone.

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 action (preview of RIT form content including texts and attachments) and implies a purpose (show before saving). It distinguishes itself from a save tool by mentioning 'antes de salvar', but does not name a sibling alternative. Clear enough for an agent to understand the core function.

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 instruction 'mostre ao docente antes de salvar' gives clear context: use this tool to show the teacher what will be sent before committing a save. No explicit when-not conditions or alternative tool names are provided, but the intended workflow position 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 this is a non-read-only, idempotent, non-destructive write, so the safety profile is covered. The description usefully adds the email-integration source and the base64 attachment convention, but says nothing about permissions, what is persisted, or side effects on registration.

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?

Three short sentences, front-loaded with the action and then the input-format guidance. No wasted prose, though the attachment sentence is the weakest link in 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 4-required-parameter write tool with no output schema and 0% schema coverage, the description explains only two inputs and omits expected values for the required semestre/assunto/remetente fields and the role of id_mensagem. An agent would likely have to guess at most arguments.

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, so the burden is fully on the description. It only clarifies 'data' (accepted formats) and 'anexo_base64' (base64 PDF), leaving semestre, assunto, remetente, texto, anexo_nome and id_mensagem completely unexplained.

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 ('Registra uma ata/convocação') and adds the source context ('encontrada no e-mail'). However, it does not distinguish itself from the very similar sibling 'registrar_atas_gmail', leaving the boundary between the two 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 implies usage context (records a minute/summons coming from the host's email integration) and gives a conditional instruction for the attachment ('Envie o PDF anexo em base64 se tiver acesso a ele'). It does not state when to prefer this over 'registrar_atas_gmail' or any other sibling, nor any prerequisites.

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 the operation is a non-destructive, idempotent write with open-world access, so the safety profile is covered. The description adds one genuinely new behavior beyond the annotations — it downloads the attached PDF — but says nothing about permissions/auth requirements, what happens to unselected candidates, or where the registration is persisted.

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?

A single front-loaded sentence with no filler; the key action and its dependency are stated immediately. It is efficient, though arguably too terse for a mutation tool with undocumented parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description need not cover return values, and annotations cover the write/idempotency profile. However, for a 2-parameter write tool at 0% schema coverage, the missing 'semestre' format and the ambiguity about where the record is stored leave a real 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 0% for two required parameters, so the description must carry the burden. It does explain the provenance of 'numeros' (from buscar_atas_gmail), but gives no format or expected value for 'semestre' and never clarifies that 'numeros' is an integer array, leaving half the inputs 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 and resource ('registra as candidatas escolhidas pelo docente') and clarifies which entries are affected by pointing to the source of the numbers. It is distinguishable from siblings like buscar_atas_gmail, though it does not clearly separate itself from registrar_ata or say where the registration lands (local vs. SUAP).

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?

Establishes a clear workflow dependency: the 'numeros' argument comes from buscar_atas_gmail and only the entries chosen by the docente should be passed. No explicit when-not-to-use or alternative is given, so it stops short of the top score.

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 the mutation/idempotency profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), lowering the disclosure bar. The description adds useful behavioral context about the decision semantics and a special-case workflow, but does not address reversibility, permissions, or effects on unlisted pendências.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first sentence and the decision list and special case follow in a tight, scannable form. No filler, though it is slightly dense in domain shorthand.

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 mutation tool with 4 parameters, 0% schema coverage, and sibling-tool inputs, the description covers the decision enum and a special case but leaves `semestre` and `justificativa` semantics unaddressed. With no output schema it needn't describe returns, but the parameter gaps hold it to 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?

With 0% schema description coverage the description must carry the parameter burden. It documents the `decisao` values well (manter | remover_item | justificar | ignorar) and notes that `justificativa` is required for 'justificar', and explains where `numeros` come from; however `semestre` and the format of `justificativa` remain undocumented, so compensation is partial.

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 ('Registra a decisão DO DOCENTE sobre uma ou mais pendências') and grounds it by naming the source tools (`preparar_rit`/`resumo_semestre`) whose numbers it consumes. An agent can distinguish this from siblings like detalhar_pendencia or preparar_rit 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?

It gives strong contextual routing: the decision values are spelled out and a conditional workflow is provided for the 'lattes_sem_comprovante' case (put proof in `pasta_entrada` and use 'manter', or 'ignorar' if it doesn't enter the RIT). There is no explicit when-not clause or comparison against a competing tool, so it stops short of a 5.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful context about what the summary contains (pendencies, attachments, texts), but it does not disclose any behavioral traits beyond output content, such as whether it aggregates live data or caches results.

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 a single, front-loaded sentence with no filler, listing the summary's components efficiently. Every element earns its place in a compact form.

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, the description helpfully enumerates what the summary returns (items, pendencies, attachments, texts). However, it omits critical parameter format details and any usage context, leaving the definition only partially complete for an agent.

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?

The single required parameter 'semestre' has 0% schema description coverage, and the description provides no format, examples, or meaning beyond 'do semestre'. An agent cannot determine whether to pass '2024.1', '2024-1', or a name, so the description fails to compensate for the missing schema 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?

The description names the resource (semester collection) and enumerates the outputs (items by topic, numbered pending issues, attachments, texts), which tells an agent what the tool produces. However, it does not differentiate this summary from siblings like listar_semestres or coletar_semestre, and it lacks a verb to clarify that it generates a summary.

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 when-to-use guidance, no conditions, and no mention of alternatives such as listar_semestres or coletar_semestre. The description only lists contents, leaving the agent to infer when this summary is appropriate.

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, but the description adds important behavioral context: saves as draft, never submits, and requires explicit approval before calling. It does not explain what happens if confirmado is false or how existing content is affected, leaving some gaps.

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, front-loaded with the core action and a key constraint, followed by a concise usage condition. Zero 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?

Given the tool's complexity (write operation, annotations, no output schema), the description covers the essential behavior and the critical approval gate. The missing explanation of the semestre parameter is a notable gap, but overall it is sufficient for safe 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 carry parameter meaning. It explains confirmado (must be true after approval) but says nothing about the required semestre parameter, leaving half the parameters 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 (Grava), resources (textos e anexos) and target (formulário do RIT), and clarifies the output state (RASCUNHO) plus a critical constraint (Nunca entrega). This lets an agent distinguish it from submission tools 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?

Provides a clear invocation condition: only call with confirmado=true after the professor explicitly approves the preview. It does not name alternative tools for submitting or other draft-saving paths, but the 'never submits' note implicitly rules out submission use.

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 this as a non-read-only, idempotent, non-destructive write within a closed world. The description adds a genuine behavioral constraint beyond the schema: only a simple HTML subset (p, ul, li, strong) is accepted. It does not state auth requirements or overwrite semantics, so it exceeds the annotation bar but only modestly.

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?

A single front-loaded sentence with the verb first and no wasted words. Its brevity is efficient, though partly a byproduct of under-specification rather than deliberate compression.

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 write tool with no annotations explaining consequences, no output schema, and three fully undocumented parameters, the description is too thin. It should at minimum explain what 'semestre'/'topico' expect and whether saving overwrites an existing report.

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 all three required parameters. The description clarifies the expected content of 'html' (simple HTML subset), which is real value, but says nothing about the semantics, format, or valid values of 'semestre' and 'topico' beyond their names.

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 ('Grava o Relato') and names the two targets: a topic or the special 'alteracoes' entry. An agent can tell what is written, though it does not differentiate this tool from siblings such as gerar_alteracoes or registrar_ata.

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 implies the tool persists a report, but gives no when-to-use guidance, no prerequisites, and never contrasts it with the many sibling tools that also handle topics or alterations. The 'de um tópico ou de alteracoes' clause describes the target, not the selection condition.

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 and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond them: it consults the latest release and results are served from a one-day cache, warning the agent that the answer may be up to a day stale.

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?

A single front-loaded sentence states the action, its data source, and its caching caveat with zero filler. Nothing could be cut without losing information.

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 zero-parameter read-only check, the description covers purpose plus the cache caveat, which is the main behavioral nuance. It stops short of indicating the shape of the answer (boolean vs. version string), but there is no output schema, so that gap is minor.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies with no evidence of missing parameter 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 and resource: it reports whether a new version of Expeditto exists by querying the latest release. This is clearly distinguishable from the sibling atualizar_expeditto (which applies the update), though the description never names that sibling 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?

Usage is only implied — an agent can infer this is a pre-update check that pairs with atualizar_expeditto, but the description gives no explicit when-to-use statement, no prerequisites, and no named alternative.

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