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

Beyond the annotations, it discloses that `get` writes the attachment to the local downloads folder and returns its path, clarifying the meaningful side effect behind `readOnlyHint: false`. It does not explain filename collisions, overwrite behavior, or listing output, but nothing contradicts the non-destructive 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 single compact sentence front-loads the resource and efficiently maps both actions without filler. Although terse, every clause contributes useful operational or output 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?

Together, the description and schema supply the required target, action default, attachment numbering, download destination, and `get` result, which is enough for most invocations. With no output schema, the lack of listing-output details and file collision or error behavior prevents full 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?

Schema coverage is 100%, and the schema already documents the `alvo` formats, `acao` enum and default, and the source and constraints of `n`. The description reinforces the roles of `acao` and `n` but adds little parameter meaning beyond those structured fields, making the baseline score appropriate.

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 identifies the resource as email attachments and distinguishes both operations: `ls` lists them, while `get` downloads attachment `n`. It compensates well for the opaque name `att`, but does not explicitly contrast the tool with its sibling mail 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 concrete action-selection guidance: use `acao ls` to list and `acao get` with `n` to download. It provides no exclusions or sibling alternatives, and the prerequisite of obtaining `n` from `att ls` appears only in the schema rather than the description.

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=false and destructiveHint=false, but silence on what the non-read action actually does. The description fills exactly that gap: 'trocar' disconnects the current session and requires re-login, a side effect an agent must know before invoking. It does not say what happens if no account is connected or whether the switch can fail, so it is useful but not exhaustive.

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 with no filler: the content overview comes first, then the risky action. The telegraphic, unpunctuated style is hard to parse for non-Portuguese readers and omits an explicit subject/verb, 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 single enum parameter with no output schema, the description does list what the response contains (email, folders with totals and unread, categories), which is the main thing needed. It still omits the not-connected state and whether 'info' returns anything else, leaving a small but 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 coverage is 100% but the schema description for 'acao' is merely 'info ou trocar', restating the enum. The prose adds real semantics by explaining that 'trocar' triggers a disconnect and a new login, which the enum alone does not convey. 'info' is left unexplained, though it is inferable from the default field listing.

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 name 'cx' and null title carry zero meaning on their own, and the description is a noun-phrase listing of fields ('email, pastas com totais e não lidos, categorias') rather than an explicit verb+resource statement. An agent can infer this reports the connected account's state, but only by interpretation, not by a stated action.

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 second sentence implicitly tells when to use the 'trocar' branch — it disconnects and prompts for another account's login, which signals it is a deliberate switch, not a passive read. There is no explicit when-to-use versus the sibling tools (ls, find, att) nor any advice on defaulting to 'info', so guidance 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 declare readOnlyHint=false and destructiveHint=false, so mutability is known; the description adds the important trait that nothing is transmitted and drafts must be sent separately. It does not say what 'editar' does to existing fields (full replace vs merge), whether drafts are duplicated, or what identifier is returned for the later snd call.

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 core action and the no-send constraint, then the handoff to snd. No redundant wording.

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?

All parameters are optional and annotations cover safety, so the description plus schema is largely sufficient for correct invocation. The minor gap is not clarifying the draft identifier returned by 'editar'/'novo' that 'snd alvo' would consume, given there is 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 coverage is 80%, so the schema already carries most parameter meaning. The description reinforces the 'alvo' linkage to snd and covers the 'tipo' family, but adds no format or content rules (e.g. whether 'corpo'/'assunto' are required for each tipo).

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 pair (create/edit) and resource (draft) plus a crucial negative scope: 'sem enviar'. It also names the sibling to use afterwards (snd), so an agent can distinguish it from the send tools without inspecting 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 clearly routes the agent: draft here, then send with 'snd alvo'. However it never explains when to pick each 'tipo' (novo vs resposta vs encaminhar) versus the dedicated reply/forward siblings (rp, fw), leaving that 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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds only that this is Outlook-backed search; it says nothing about the result cap (default 15, max 50), whether matches are ranked, or that an empty 'pasta' means a global sweep — details that matter for a search operation.

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 first and trigger second, with no filler. The parenthetical '(busca do Outlook)' earns its place by identifying the search backend.

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

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 80%, so the baseline is 3. The description reinforces the field selection (texto/remetente/assunto mapping to the 'campo' enum), which adds a little meaning, but says nothing about 'periodo', 'pasta', or 'qtd' that the schema does not already carry.

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 ('Busca emails') plus the searchable fields (texto, remetente, assunto) and the underlying engine (busca do Outlook), so an agent immediately knows this is an email search tool. It does not differentiate itself from any of the cryptic siblings (ls, cx, tag), leaving the 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?

Explicitly says when to reach for it: 'quando o usuário menciona alguém ou um assunto específico' — a concrete trigger condition. There is no when-not guidance and no named alternative for listing rather than searching (e.g., ls), so the guidance is clear but incomplete.

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 openWorldHint=true and destructiveHint=true, so the safety profile is known. The description reinforces this with 'Envia de verdade' (it really sends) and adds the important non-annotation detail that a confirmation step is required, though it stops short of describing irreversibility or rate/auth constraints.

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, both carrying information: one defines the operation and its optional modifier, the other flags real-world sending and the confirmation requirement. Zero padding and the key risk warning is placed last for emphasis.

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, open-world mutation tool with no output schema, the description covers what it does, that it truly sends, and that confirmation is involved; the confirmation-code mechanics are covered by the 'cf' schema description. It could still say more about what a first (unconfirmed) call returns and any recipient limits.

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 the four parameters are already fully documented, including the 'cf' confirmation code and the 'alvo' id formats. The description only adds that 'nota' is optional, which is marginal value beyond the schema — baseline 3 applies.

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 verb and resource — forwarding an email to other recipients with an optional note — which usefully decodes the cryptic name 'fw'. It does not, however, distinguish this from sibling tools like 'snd' (send) or 'rp' (reply), which an agent could easily confuse with forwarding.

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?

'Envia de verdade; pede confirmação' implies a real send behind a confirmation step, which is contextual usage guidance. But there is no explicit statement of when to choose 'fw' over 'snd' or 'rp', and no prerequisites or exclusion conditions are given.

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 safety is covered. The description adds real behavioral detail beyond them: results are ordered most-recent-first and returned grouped as one line per conversation, which tells the agent what the payload looks like. Pagination behavior is left to the schema's pg/qtd parameters.

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 compact sentences with zero filler. The core listing behavior and its output shape are front-loaded, and the usage hints follow as a secondary sentence.

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, six-parameter listing tool with no output schema, the description covers what it returns and how results are ordered and grouped. Combined with full schema coverage and the annotations, an agent has what it needs to invoke it correctly, though a note on result-limit/truncation behavior would seal 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?

Schema description coverage is 100%, so every parameter is already documented in the schema; baseline 3 applies. The description hints at filtro ('não lidos') and periodo ('hoje') and at the conversa grouping, but adds no syntax or semantics beyond what the schema enums already state.

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 ('Lista') and resource ('emails de uma pasta') plus ordering ('mais recentes primeiro') and output shape ('uma linha por conversa'). It implicitly contrasts with the search sibling 'find', though it never names it, so sibling differentiation is only partial.

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 concrete usage contexts ('ver a caixa, não lidos, emails de hoje etc.') that map directly onto the filtro and periodo parameters. It stops short of stating when to prefer a sibling such as find over this listing tool, so no explicit alternatives are offered.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered and the description only needs to add context. It adds the enumerable state list but says nothing about scope of effect (all folders vs current list), error behaviour for invalid targets, or how 'lista'/'ultimo' targets are resolved at call time.

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 waste-free sentence that front-loads the verb and resource. It is minimal for the amount of behaviour the tool actually covers, but nothing in it is redundant.

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 flag-setting tool with full schema coverage, explicit annotations and no output schema, the description is sufficient to call it correctly. The main omission is sibling differentiation from 'tag' and clarification of list-scoped targeting, which are useful but not blocking.

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, and the description's list of marks simply echoes the 'marca' enum. It does not explain the 'alvos' special values ('atual', 'ultimo', 'lista') beyond what the schema says, so baseline 3 applies.

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 verb (marks) and resource (emails) plus the full set of target states, which disambiguates the cryptic tool name 'mk'. It does not distinguish itself from siblings like 'tag', which an agent could plausibly reach for instead.

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 or when-not-to-use guidance and no named alternative. The agent must infer from the verb alone that this sets flags rather than applying tags (the 'tag' sibling) or moving mail ('mv').

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 and destructiveHint=false, and the description's 'Não exclui' consistently reinforces the non-destructive behavior. It adds little beyond that: permissions, destination-existence handling, and source-folder side effects are not described.

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 wasted wording. It compactly includes the core action, archival mapping, and non-deletion caveat.

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 two-parameter mutation with full schema coverage and annotations covering safety, the description is sufficient to invoke correctly. Minor omissions about destination existence or return behavior are acceptable given the absence of an 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 coverage is 100% and both 'alvos' and 'destino' are fully documented in the schema. The description adds a useful archive mapping, but provides no extra syntax or behavior for 'alvos', so the baseline 3 is appropriate.

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: moving emails to another folder. It also clarifies the archival mapping and non-deletion scope, but does not distinguish this from siblings such as rm, tag, or mk.

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 usage mapping, 'arquivar = destino arquivo', and a negative boundary, 'Não exclui'. However, it does not explicitly say when to use this over alternatives like rm or tag, so guidance 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, so safety is covered. The description adds genuinely useful behavior beyond that: the returned body is post-processed (citations, signature and legal notice stripped) and thread mode expands to the full conversation, so the agent knows the output is not the raw message. Missing: behavior for invalid/already-deleted targets and whether the read marks the message as read (the 'atual' pointer implies state changes on read).

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 clauses, front-loaded with the main action, with zero filler. It is terse to the point of omitting useful routing information, but nothing present 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 2-parameter read tool with full schema coverage and read-only annotations, the description covers what is returned (cleaned body) and the thread variant. It lacks only edge-case behavior (unknown id, side effects on the read/unread state), which is minor given the structured fields already supplied.

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 100%, with both parameters documented, including the three enum values of modo. The description only echoes the thread mode, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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 ('Lê um email') and adds a distinguishing detail: the body returned is cleaned of quotes, signature and legal disclaimer. This is enough for an agent to tell it apart from listing/searching siblings like ls and find, though no sibling is named 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 implied by the resource (read one email by short id or the 'atual'/'ultimo' pointers), and the description notes thread mode shows the whole conversation. It never states when to prefer this over att (attachments) or rp, nor any exclusions or error conditions.

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=false, but the description adds the crucial qualifier that deleted emails go to "Itens Excluídos" and are recoverable, plus the fact that a confirmation step exists. That is genuine behavioral context an agent cannot get from the annotation alone, though the response format of the confirmation step is not described.

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, front-loaded sentences with zero filler: the action and its reversibility come first, the confirmation requirement second. Nothing is wasted and nothing important 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?

With only two parameters, full schema coverage, and annotations covering the destructive profile, the description supplies what is missing: reversibility and the confirmation requirement. It stops short of explaining the full two-call handshake or what a batch result looks like, but no output schema exists to carry that either.

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 100%, so both parameters are already documented, including the meaning of alvos (short ids, 'atual', 'ultimo', 'lista') and cf (confirmation code from the first call). The description only indirectly alludes to the two-call protocol through "Pede confirmação" and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 verb and resource in Portuguese ("Exclui emails"), which resolves the ambiguity of the cryptic tool name "rm". It does not, however, differentiate itself from siblings such as rd, mv, or cx, so an agent must still infer that this is the email-deletion tool rather than a folder or attachment operation.

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?

"Pede confirmação" implies the two-step confirmation flow and the recoverable nature hints that this is a safe-ish bulk operation, but there is no explicit guidance on when to choose rm over alternatives like mv (move) or cx. 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 flag destructiveHint and openWorldHint, but the description adds real value by warning 'Envia de verdade' (it actually sends) and 'pede confirmação' (a confirmation step is required), which explains the two-phase cf flow implied by the schema. It still does not describe what the confirmation response looks like or what happens after the send.

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 with the action and its most important side effect front-loaded. Nothing is wasted and nothing needs reordering.

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, open-world send tool with a fully documented schema, the description covers the essential risk and confirmation behavior. The main remaining gap is that the confirmation round-trip is only hinted at rather than spelled out, but the schema's cf parameter fills that in.

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 100%, so all four parameters are already documented, and the description only echoes the 'todos' scope with 'ao remetente ou a todos'. No additional meaning (e.g., what 'atual'/'ultimo' resolve to, or when cf is mandatory) is contributed beyond 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?

States a specific verb and resource ('Responde um email') plus the reply scope ('ao remetente ou a todos'), which is enough to separate it from siblings like snd (send) or fw (forward). It does not explicitly name the sibling it is not, 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 implied by the verb: use this when replying to an existing email rather than composing a new one. There is no explicit when-not guidance or named alternative (e.g., snd for new mail, fw for forwarding), so the agent must infer the 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 destructiveHint=true and openWorldHint=true; the description reinforces this with "Envia de verdade", making clear the side effect is real and externally visible rather than a staging action. "Pede confirmação" adds genuine behavioral context — a confirmation gate — that the annotations do not convey. It does not explain what happens if confirmation is absent or rejected, keeping it below 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 compact sentences with zero filler: the first front-loads the two modes and their selecting parameters, the second front-loads the irreversibility and confirmation requirement. Nothing is repeated from the schema or annotations verbatim.

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, externally-visible send tool with 6 parameters and no output schema, the definition omits how the confirmation flow actually works (that cf must come from a first call), says nothing about cc, and gives no indication of what a successful send returns. The essentials for choosing the tool are present, but the mechanics of the guarded write are under-described.

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 67%, and the description adds real meaning by explaining the mutual exclusivity of alvo versus para/assunto/corpo, which the schema itself does not state. It leaves cc entirely unmentioned and does not explain the confirmation code cf, though the schema does describe cf. Net positive over the schema baseline.

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 concrete verb and resource ("Envia um email novo" / "envia um rascunho existente") and distinguishes its two operating modes via the parameter sets that select them. The cryptic tool name "snd" is fully resolved by the text. It stops short of naming a sibling, but none of the listed siblings (ls, find, rd, att...) appears to be a competing send operation.

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 clear mode-selection guidance: use para/assunto/corpo for a new message, or alvo to send an existing draft. The phrase "pede confirmação" signals a confirmation step before the send occurs. It offers no explicit exclusions or prerequisites (e.g. auth or quota conditions), so it sits at 4 rather than 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 non-read-only, non-destructive, idempotent, closed-world behavior, which matches a category add/remove. The description adds the useful fact that it operates on many emails in one call, but says nothing about what happens when a category does not yet exist, whether missing categories are created, or what the call returns.

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 action and the bulk scope come first. It is efficient, though one extra clause about the add-vs-remove selector or the 'lista' target would have been worth the 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 three-parameter bulk mutation with full schema coverage and four annotations, the essentials are covered by structured fields rather than the prose. What remains thin is behavioral detail an agent would want before bulk-tagging: no output shape (none declared) and no note that removing a category from untagged items is a no-op.

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 the schema already documents cat, acao, and the alvos oneOf including the 'lista' sentinel. The description adds only the implicit plural framing ('vários emails'), with no syntax, limits, or semantics beyond the schema. Baseline 3 applies.

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 pair (adds or removes), a specific resource (an Outlook category), and the scope (multiple emails at once). An agent can tell this is the bulk-category tagging tool rather than a plain delete or move. It stops short of naming the sibling it contrasts with (e.g., rm), which keeps 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?

Usage is only implied: the sentence tells you the tool applies categories to several emails at once, suggesting bulk use over the singular siblings. There is no explicit 'use this when' or 'do not use this for' statement, and no mention of how it relates to rm or mv when the goal is removal.

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