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

With no annotations, the description carries the full disclosure burden. It usefully discloses that the password is not returned ("sem senha") and names the returned artifacts, which is genuine behavioral content. However, it says nothing about read-only nature, permissions/auth requirements, or behavior when the account is unset (the parameter defaults to an empty string).

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?

One compact sentence with the resource front-loaded and the returned payload enumerated; no filler. It could carry one more clause on parameter format without becoming bloated.

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

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

For a read-only introspection tool with no output schema, the description usefully previews the return payload (config minus password, IMAP capabilities, Sent folder). It is nonetheless incomplete on how to target an account and on the absence of authentication/error behavior.

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 "account" parameter has 0% schema description coverage and a default of empty string. The description only implies "de uma conta" without explaining whether this is a name, email address, or index, nor what happens when the default empty value is used. It fails to compensate for the coverage gap.

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

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

States a specific verb ("Mostra") and resource ("configuração ativa de uma conta"), and enumerates the extra content returned: IMAP server capabilities and the detected Sent folder. It is distinguishable from most siblings, though it never explicitly contrasts itself with list_accounts, which an agent comparing the two must infer.

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 prerequisite or exclusion statement, and no mention of the sibling tools that overlap most closely (list_accounts, list_folders). Usage must be entirely inferred from the noun "info".

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?

No annotations are provided, so the description carries full behavioral burden. It discloses the subfolder nesting convention, but says nothing about what happens if the folder already exists, permission/auth requirements, or account scoping for the account parameter.

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 terse sentences with the core action front-loaded and a practical example appended. No filler, though the two delimiter variants could be explained more briefly.

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 annotations, no output schema, and one of two parameters undocumented, the description leaves significant gaps for a mutation tool: no return behavior, no duplicate-handling, and no account semantics.

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

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

Schema coverage is 0% across 2 parameters. The description meaningfully documents the 'name' parameter's subfolder delimiter syntax with concrete examples, but the 'account' parameter (with default "") is left entirely undefined in both schema and description.

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

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

The description states a specific verb and resource ('Cria uma pasta') which is clear and distinguishes it from siblings like delete_folder and rename_folder. It does not explicitly name an alternative, but the create action 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?

There is no guidance on when to create a folder versus using list_folders, move_email, or rename_folder, and no mention of prerequisites or conditions. The example is about parameter syntax, not usage 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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose the two-stage semantics: mark \Deleted, then permanently remove from the folder only when expunge=True. That is genuinely useful destructive-behavior context. It stops short of stating auth requirements or irreversibility beyond expunge, so not a 5.

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

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

Two sentences, zero waste, and the destructive semantics are front-loaded ahead of the routing hint. Every phrase 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 4-parameter mutation tool with no annotations and no output schema, the description covers the core danger (permanent removal) and the sibling routing, but leaves folder/uid conventions and the non-expunge outcome implicit. Adequate but with visible gaps.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate. It explains expunge's effect well ('se expunge=True, remove definitivamente da pasta'), but says nothing about uids, folder, or account formats, leaving half the surface 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?

States a specific verb (Exclui) and resource (e-mails) and immediately distinguishes the operation from the sibling move_email by naming the alternative explicitly. An agent can tell delete from move-to-trash without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: for 'mover para a lixeira' use move_email to the Trash folder. This is a concrete when-to-use-this vs when-to-use-another statement, not inferred 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?

No annotations are provided, so the description must carry the full burden. It states the action is irreversible and deletes all messages within, which is important behavioral context. However, it doesn't mention permissions required, whether the account parameter affects scope, or what happens to subfolders. For a destructive tool, more transparency is needed.

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 short sentence in Portuguese, front-loading the action and consequence. It's efficient with no wasted words, though it could benefit from additional context.

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 no annotations, no output schema, and 0% schema coverage, the description is incomplete. It fails to address key details like required permissions, scope of deletion (subfolders?), account parameter behavior, and error conditions. For a destructive two-parameter tool, this is inadequate.

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 should compensate. It mentions 'pasta' (folder) but doesn't clarify the 'name' parameter's format or the 'account' parameter's role (e.g., which account to use). The schema has no descriptions, leaving both parameters undocumented in both schema and description.

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

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

The description states a clear verb (remove) and resource (folder), and adds that it deletes all messages within. However, it doesn't clearly distinguish from sibling tools like delete_email or explain folder hierarchy impact. Vague about whether it's a single folder or recursive 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?

No guidance on when to use this tool versus alternatives like move_email or delete_email. It doesn't specify prerequisites or conditions. The only implied usage is for removing folders, but no context is given for when that's 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?

No annotations are provided, so the description carries the full burden. It discloses the index=-1 behavior and the empty-dest_dir fallback to the account's attachments folder, which is genuinely useful. It omits what happens on out-of-range index, whether files are overwritten, and any auth/account requirements.

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

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

Three compact sentences with no filler; the core action is front-loaded and the parameter behaviors follow logically. Slight redundancy in restating the return value when an output schema exists.

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?

Return value is covered by the output schema, so that sentence is optional padding. With 5 parameters at 0% schema coverage and no annotations, the definition leaves uid/folder/account semantics and the mutation/permission profile unexplained.

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 and only partly does: index (with the -1 sentinel and cross-reference to read_email) and dest_dir (empty = account attachment folder) are clarified. The required uid and folder, plus account, receive no explanation at all.

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

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

States a specific verb and resource ('salva anexos de um e-mail em disco'), which is clearly distinct from read_email or get_raw_email. It also cross-references a sibling ('índice conforme read_email'), aiding disambiguation, but does not explicitly frame itself against the 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?

Explains the two usage modes via index (-1 saves all vs. single attachment) and the dest_dir default, which is useful operational guidance. However, it never states when to choose this tool over read_email / get_raw_email, nor notes prerequisites for having an email selected.

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?

No annotations, so the description carries the full burden. It discloses that original attachments are carried over and that a text body is supplied, but says nothing about immediate dispatch, whether a copy is saved to Sent by default, or any permission requirements for an 8-parameter mutation 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?

A single compact sentence with the key behavior (body + original attachments) front-loaded and no filler. It is efficient, though brevity here reflects under-specification as much as tight writing.

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 no annotations, no output schema, and 8 parameters at 0% coverage, one sentence is not enough. An agent cannot infer how to identify the source email or what save_to_sent and account do.

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

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

Schema description coverage is 0%, so the description must compensate, but it only loosely maps to body, include_attachments, and to/cc. Critical parameters like folder, uid, account, and save_to_sent are entirely unexplained, leaving half the schema opaque.

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

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

States a specific verb and resource ("Encaminha um e-mail") plus the payload composition (text body + original attachments) and target (new recipients). This distinguishes it from a generic send, though it never names reply_email or send_email 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?

No guidance on when to forward versus reply_email or send_email, and no prerequisites (e.g., the email must already exist in a folder). Usage is only implied by the tool name.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses what is returned (RFC822 source) but says nothing about auth requirements, rate limits, or truncation behavior even though a max_chars parameter (default 50000) implies output can be cut off.

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 capability and followed by a usage hint. No wasted words, though it is arguably too terse given the 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?

An output schema exists so return values need not be explained, but with zero annotation coverage and 0% parameter descriptions, the definition leaves an agent guessing about scoping, truncation, and when raw extraction is appropriate versus read_email.

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 4 parameters (uid, folder, account, max_chars), and the description explains none of them. It does not compensate for the coverage gap, leaving the meaning of account scoping and max_chars truncation entirely 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+resource: it returns the complete RFC822 source (raw headers + MIME) of a message. The word 'raw' distinguishes it in spirit from a parsed reader like read_email, but no sibling is named or contrasted 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?

'Útil para diagnóstico' hints at the use case (diagnostics), which is implied usage guidance. However, it never states when to prefer this over read_email or under what conditions raw source is needed, and no exclusions 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?

No annotations are provided, so the description carries the full burden. It's a read-only operation by nature, but the description doesn't confirm safety, return format, or side effects. It does add the useful detail that the default account is included, going slightly beyond the name.

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, concise sentence that front-loads the main purpose and includes the key detail about the default account. No wasted words.

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

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

Given the simplicity of the tool (no parameters, no output schema), the description is minimally adequate. It could have been improved by explicitly noting it's a read-only operation or how it relates to sibling tools, but it covers the basics.

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 baseline is 4. The description appropriately adds no parameter details since none are needed.

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

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

The description clearly states it lists configured email accounts and identifies the default one. The verb and resource are specific, though it doesn't explicitly differentiate from sibling tools like account_info or search_all_accounts.

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 description—one would use this to see available accounts. However, it doesn't state when to use this versus account_info or search_all_accounts, leaving some ambiguity.

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?

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait — that with_counts=True is slower because it fetches totals and unread counts — and 'Lista' implies a read-only operation. However, it says nothing about permissions, account resolution failure behavior, or pagination.

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 core action and followed by the optional flag's tradeoff, plus a compact parameter gloss. Every clause carries information; 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 two-parameter list tool with an output schema covering return values, the description supplies enough: purpose, both parameter semantics, and the performance caveat. The only gap is the absence of any permission or error-handling context, which for a read-only listing 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?

Schema description coverage is 0%, so the description must compensate, and it does: 'account' is documented as a name or e-mail with empty meaning the default account, and 'with_counts' as including totals and unread counts at a performance cost. Both parameters gain meaning beyond the bare schema types.

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 ('Lista todas as pastas (mailboxes) de uma conta') with clear scope. It is unmistakably distinct from the folder-mutating siblings (create_folder, delete_folder, rename_folder) and from message-level tools like search_emails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by describing what the tool returns and the with_counts variant, but never states when to prefer this over alternatives such as account_info or how it relates to folder listing elsewhere. Guidance is inferred rather than explicit, with 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?

With no annotations, the description carries the full behavioral burden, and it does add real value by disclosing the fallback mechanism (MOVE when supported, otherwise COPY + delete + EXPUNGE), which signals a potentially destructive operation. However, it omits permissions/auth requirements, failure behavior if the destination is missing, and whether the EXPUNGE is recoverable.

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, tightly written sentence with the operation front-loaded and the implementation nuance parenthesized. Nothing is redundant, though the brevity is partly owed to omitted necessary 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 4-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It covers the mechanism but leaves parameter meaning, preconditions, and post-move state unexplained.

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, and it does not. It never explains what 'uids', 'folder', 'destination', or 'account' mean, their formats, or how folder/destination relate to each other, leaving four undocumented parameters.

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 ('Move') and resource ('e-mails') plus a scoping constraint ('para outra pasta da mesma conta'), which cleanly distinguishes it from siblings like delete_email or copy-oriented tools. It stops short of naming any sibling explicitly, so differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The same-account constraint implies when this tool applies versus a hypothetical cross-account move, but no alternative tool or when-not-to-use condition is named. Usage has to be inferred from the parenthetical scope note.

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?

With no annotations, the description carries the full behavioral burden. It discloses the body format (text default, HTML optional) and the max_chars=0 default-limit behavior, but omits the notable side effect that mark_as_read defaults to true, and says nothing about permissions or response shape.

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 tight clauses with no filler: the read purpose comes first, followed by the account note and the download_attachment pointer. Well front-loaded, though a slight jumble between the return-value clause and the parameter notes.

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 and no annotations means the description should carry everything, and it does cover body format and the max_chars default. However, the undisclosed mark_as_read behavior and the implicit folder parameter leave a meaningful gap for a 6-parameter tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains uid, account (empty = default account), max_chars=0, and prefer_html, but leaves mark_as_read undocumented despite its default-true side effect; folder is left implicit. Roughly half the parameters get meaning, so it only partially compensates.

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

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

The description states a specific verb+resource ('Lê um e-mail completo pelo UID') and enumerates what is returned: headers, body (text or HTML), and attachment list. This clearly distinguishes it from a raw-email fetch, though it never names get_raw_email as the contrasting sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one useful routing hint – use download_attachment to save attachments – but provides no guidance on when to prefer this over get_raw_email, search_emails, or list_folders. Usage context 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not whether the rename requires auth, whether it is reversible, what happens if new_name already exists, or whether the folder's contents are affected.

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 sentence is short, but this is under-specification rather than conciseness: there is no front-loaded scope, no parameter mapping, and nothing that earns its place beyond echoing the tool name.

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 tool with three undocumented parameters, zero annotations, and no output schema, the description is completely inadequate — an agent cannot distinguish the two required string parameters or predict side effects.

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 parameters, and the description adds nothing. It does not clarify that "name" identifies the existing folder and "new_name" is the target, nor what "account" selects — a critical ambiguity in a rename tool.

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

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

"Renomeia uma pasta" is a literal restatement of the tool name rename_folder — same verb, same resource — with no scope, no differentiation from siblings like create_folder/delete_folder/move_email, and no hint about what makes a rename succeed or fail.

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 preconditions (e.g. folder must exist, new_name must not collide), and no mention of alternatives such as create_folder + move. The agent is left to infer everything from the name.

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?

No annotations are provided, so the description carries full burden. It discloses important side effects: threading headers are set and the original email is marked as answered. It does not mention whether the reply is saved to Sent, permission needs, or what happens to attachments – though some of these are covered by parameters with defaults.

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 two sentences: the first explains the core action and side effects, the second clarifies the account parameter. Front-loaded with the main purpose, but the second sentence is slightly tangential to the overall action description.

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

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

The tool has 9 parameters and no output schema. The description covers only the account parameter and core behavior. It does not address return values (e.g., new message ID), handling of attachments, or how flags are set. For a mutation tool with many parameters, this is minimally adequate but leaves significant gaps.

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

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

Schema description coverage is 0%, so the schema provides only titles and no descriptions for 9 parameters. The description clarifies 'account' (empty = default account), but does not explain the semantics of uid, folder, reply_all, save_to_sent, quote_original, html, or attachments. This partially compensates but leaves many gaps.

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 (reply) and resource (email), and explicitly describes behavior: maintains threading (In-Reply-To/References) and marks the original as answered. This distinguishes it from siblings like send_email (new mail) and forward_email (no threading).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies context: replying to an existing email, as evidenced by required folder and uid. However, it doesn't explicitly say when to prefer reply_email over send_email or forward_email, or note handling of reply_all vs. normal reply.

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?

No annotations exist, so the description carries the full burden. It does disclose a valuable non-obvious trait: partial-failure tolerance ('Erros de uma conta não interrompem as demais') and that output is grouped by account. It omits read-only/rate-limit/permission behavior and the fact that a fixed folder must exist in every account.

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 with no filler; the aggregate scope is front-loaded and the error-isolation caveat is placed last where it belongs. It is efficient, though it spends a sentence on an example use case rather than on parameter meaning.

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 10-parameter aggregation tool with no annotations and no output schema, the description covers only the aggregate/fan-out behavior and error isolation. It leaves the entire query-parameter surface and the shape of the per-account results undocumented, so an agent cannot confidently construct a call beyond the defaults.

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?

Ten parameters with 0% schema description coverage, and the description explains only one of them indirectly ('mesma pasta em cada uma' implies the folder argument, and results are per account). Nothing is said about to/text/since/before/sender/unseen/flagged/subject or the limit_per_account default of 10, leaving nine arguments semantically bare.

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 ('executa a mesma busca em TODAS as contas') and the aggregation scope ('resultados agrupados por conta'), which clearly separates it from the single-account search_emails sibling. The sibling is never named explicitly, so an agent must infer the contrast from the word TODAS.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides one implied use case ('o que chegou de novo em todas as caixas'), which tells the agent when this tool is appropriate. It never names search_emails as the narrower alternative, nor states any when-not condition (e.g., don't use for one account only).

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?

With no annotations, the description carries the full burden. It usefully discloses result ordering ('mais recentes primeiro'), the returned fields (UID, remetente, assunto, data, flags), and that raw_criteria bypasses the other filters. It omits read-only safety framing, pagination/limit behavior, and any cost or rate-limit notes for a 13-parameter search.

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

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

Compact and front-loaded: purpose and return shape come first, followed by tightly packed parameter notes. No filler sentences, though the terse 'chave: valor' style compresses some ideas to the point of ambiguity.

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 13-parameter tool with no annotations and no output schema, the description covers return fields and several key parameters well, but omits the limit/pagination contract and the unseen/flagged/larger_than_kb filters, which an agent cannot infer from the bare schema titles.

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 compensate, and it does for the highest-value parameters: account default behavior, date format (YYYY-MM-DD) for since/before, substring/case-insensitive semantics for sender/to/subject/text, and the raw_criteria override rule. It leaves limit, unseen, flagged, larger_than_kb, and folder entirely undocumented, but the added semantics still materially exceed 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 ('Busca e-mails em uma pasta de uma conta') and describes the return shape. The phrase 'de uma conta' implicitly distinguishes it from the sibling search_all_accounts, but that sibling is never named, so the differentiation is inferential rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is only implied: the reader must infer that this searches within one account while search_all_accounts spans accounts. It does clarify an important behavioral rule (raw_criteria overrides other filters), but gives no explicit when-to-use/when-not or prerequisite statements.

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?

With no annotations present, the description carries the full load and discloses real behavioral traits: the SMTP send path, default-account fallback, recipient separator syntax, the html flag's effect on body, and—most valuably—a secondary IMAP side effect writing a copy to Sent when save_to_sent=True. It stops short of covering authentication or failure behavior, so it is strong 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?

Each sentence is dense and earns its place, front-loading the core action before moving to parameter notes. It is telegraphic rather than verbose, though the terse style leaves some sentences borderline fragmentary.

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 10-parameter mutation tool with no annotations and no output schema, the description covers the mechanism, key parameter semantics, and the Sent-folder side effect. It omits any note on send failures or return values, but the essentials an agent needs to invoke it correctly are present.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate, and it does so for the non-obvious ones: account (empty means default), to (comma/semicolon separators), html (body treated as HTML), attachments (local file paths), and save_to_sent (Sent-folder copy). The remaining params (subject, body, cc, bcc, reply_to) go undiscussed but are largely self-evident from 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 ('Envia um e-mail') plus the transport mechanism (via SMTP), which immediately distinguishes it from siblings like reply_email and forward_email. An agent can identify the operation 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 the conditional 'account vazio = conta padrão', which is useful context, but never states when to prefer this tool over reply_email or forward_email for a thread. Usage is implied by the name rather than explained, so it sits at minimum-viable 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the core mutation semantics — a tri-state True/False/omit contract that tells the agent exactly how each flag is changed — which is the most important behavior here. It omits, however, any mention of permissions/auth needs, reversibility, whether unspecified flags are preserved, or what happens on partial failures across the UID list.

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 filler, and the flag enumeration plus the True/False/omit rule are front-loaded. It is efficient and earns its space, though the two clauses could be integrated slightly more tightly.

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 6-parameter mutation tool with no annotations and no output schema, the description covers the flag semantics well but leaves the folder/account/uids addressing context and the return behavior unexplained. An agent could invoke it correctly for the flag portion but would be guessing about account selection and multi-account scope.

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 6 parameters, so the description must compensate and it only partly does: it explains the semantics of seen/flagged/answered including the tri-state boolean logic, which is genuinely valuable beyond the bare titles 'Seen'/'Flagged'/'Answered'. The other three parameters (folder, uids, account) receive no explanation of format or accepted values, leaving half the surface documented by title 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 verb + resource ('Marca/desmarca flags em um ou mais UIDs') and enumerates exactly which flags are affected (seen, flagged, answered). It is unambiguous about what the tool does, though it never names a sibling or scope boundary relative to them (e.g. vs move_email or read_email), so it stops short of the top band.

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 operational guidance for the flag values ('Passe True para adicionar, False para remover, omita para não alterar'), which is real usage direction. However there is no when-to-use-this-vs-alternatives guidance, no note on required permissions or prerequisites, and no statement of when NOT to use it. Usage is implied rather than framed.

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