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

Annotations already mark readOnlyHint and destructiveHint, and the description reinforces this with 'Ação somente leitura' and 'Nada é movido, copiado ou modificado.' It adds context about the authorized-folder constraint and the intended user-facing communication style. No contradiction exists between description and 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 description is compact and front-loads the key behavior: read-only search by name/pattern. The user-facing phrasing instruction is an extra but legitimate addition. It is not bloated, though 'Ação somente leitura' and 'Nada é movido, copiado ou modificado' are slightly redundant with each other.

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?

Combined with the fully documented schema and annotations, the description gives enough context for an agent to call the tool correctly: what to search, where, and that it is non-destructive. There is no output schema, so the return format is not specified, but for a straightforward search tool this is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds some semantic nuance by explaining substring vs. glob matching and extension filtering, but it mostly restates what the schema already says and does not add extra meaning for 'limite' or 'recursivo'.

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 identifies the action: 'busca arquivos e pastas por nome' and specifies the scope ('dentro de uma pasta autorizada'). It also adds useful differentiation from mutation siblings by stating 'Ação somente leitura' and 'Nada é movido, copiado ou modificado.' However, it does not explicitly distinguish itself from the very similar sibling 'listar_arquivos', 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?

The description provides clear context for when to use the tool: searching by substring or glob pattern, optionally filtering by extension, within an authorized folder. It does not explicitly name alternatives or state when not to use the tool, so it lacks the explicit exclusions needed for 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?

With all annotations false, the description carries the full burden and succeeds: it discloses recursive copying, that the original is preserved, that an existing destination produces a conflict error by default, that conflictStrategy='rename' auto-generates a free name, and that operations are confined to authorized folders. This goes well beyond what annotations or schema reveal.

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 appropriately sized: core operation and conflict behavior come first, followed by required user-communication steps. Every sentence carries useful information, including the instruction not to cite the technical tool name. It is slightly long but not padded, so it earns a 4 rather than a 5.

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

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

For a mutation tool with no output schema and no annotations, the description covers the essential operational constraints: authorized folders, non-overwrite default, conflict resolution via rename, original retention, and user-facing confirmation steps. It does not specify success return values, but this is a simple copy operation and the description is otherwise complete enough for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaningful value by explaining the conflictStrategy behavior in detail (error vs. rename) and by clarifying that copy is recursive and destination-paths must respect authorized folders. This enriches the otherwise minimal schema parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Copia um arquivo ou pasta (recursivamente) para outro local'. It clearly states the scope (within authorized folders) and explicitly says the original remains in place, which distinguishes it from mover_item. An agent can tell this is a non-moving copy operation without needing to inspect siblings.

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

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

The description provides clear context for use: it copies recursively only within authorized folders, and the default conflict behavior is explained. The phrase 'o arquivo original será mantido no lugar de origem' implicitly differentiates it from mover_item. However, it does not explicitly name when to prefer this tool over alternatives or state a when-not-to-use condition, 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?

Beyond the annotations, the description reveals important behavior: recursion, tolerating existing folders, the authorized-folder requirement, and a mandatory user communication protocol with examples. This aligns with idempotentHint: true and adds meaningful operational context.

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

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

The description is front-loaded with the core behavior and then covers idempotence and interaction requirements. The scripted examples add length but are useful for consistent agent behavior, so every sentence earns its place without being 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 simple one-parameter, non-destructive creation tool, the description covers purpose, recursion, existing-folder behavior, authorization scope, and user-facing confirmation. The main gap is the lack of explicit failure handling, such as what happens when the path is unauthorized or invalid.

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%: the only parameter, 'caminho', is already described as 'Caminho completo da pasta a criar.' The description adds no new parameter-level detail such as path format, separators, or relative-path handling, so the baseline score of 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?

The description clearly states the action ('Cria uma pasta') and the resource, adding useful constraints: recursive creation, authorized parent folder, and idempotent behavior. It does not explicitly differentiate from the sibling outlook_criar_pasta, but the general vs. Outlook scope is reasonably evident.

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 when to use the tool: whenever a folder needs to be created under an authorized location. It also gives procedural guidance about informing the user before and after execution, but it does not name alternatives such as outlook_criar_pasta or state when not to use this tool.

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

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

Annotations already mark destructiveHint=true, and the description adds the crucial nuance that the action is not permanent and is reversible through the Windows Recycle Bin. It also discloses user-facing naming guidelines. There is no contradiction between the description and the annotations.

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

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

The description is front-loaded with the critical destructive warning and uses a numbered checklist that is easy to follow. It is somewhat longer than necessary and repeats 'Lixeira' several times, but every sentence carries safety-relevant information for a destructive action.

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 one-parameter tool with no output schema, the description is complete: it explains the effect, the reversibility, the required confirmation flow, and the exact user-facing language. Nothing essential to safe invocation 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?

The input schema has 100% coverage for the single parameter 'caminho', which already documents that it is the path of the file or folder to send to the Recycle Bin. The tool description adds no additional format, path-type, or validation details beyond what the schema already provides.

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: it sends a file or folder to the Windows Recycle Bin. It clearly distinguishes itself from permanent deletion by explicitly stating that it never deletes permanently and that the user can restore the item.

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 provides a clear and mandatory pre-call protocol: list the exact items, inform the user that they can be recovered, ask 'Deseja continuar?' and wait for explicit confirmation. It also states when not to invoke the tool — never by inference alone. It does not name a specific alternative tool, but the conditional usage is unambiguous.

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?

Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds meaningful behavior beyond that: it scopes listing to authorized folders, clarifies that file contents are never returned, and gives explicit user-communication instructions. This gives the agent a clear behavioral contract.

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

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

Four sentences with no filler. The read-only nature is front-loaded, followed by return-value scope, safety reassurance, and the practical recursive flag instruction. Every sentence contributes something useful for invocation.

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 relatively simple listing tool, the description is nearly complete: it names the metadata returned, confirms no content is exposed, and instructs on how to communicate with the user. With no output schema, a bit more detail about the return shape or ordering could help, but the listed fields and parameters cover most agent needs.

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 the baseline is 3. The description adds minor context about the pasta argument being authorized and the recursive flag, but mostly repeats information already present in the schema. It does not materially improve parameter understanding 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?

The description states a specific verb and resource: it lists files and folders inside an authorized directory. It clearly defines scope by saying exactly what is returned (name, path, type, extension, size, modification date) and what is not returned (file contents), which differentiates it from content-reading and modification 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?

The description gives useful operational context: it is read-only, requires no confirmation, and should be announced to the user in plain language. However, it does not explicitly tell the agent when to choose this tool over related alternatives like buscar_arquivos or obter_metadados, so usage 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description goes beyond them by specifying how to present the list (friendly names in `resumo`, full paths only when requested) and instructing a follow-up invitation to work in another folder with authorization.

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 bit longer than minimal but every sentence adds value: scope, trigger, presentation, and follow-up. It is front-loaded with the core action and remains readable.

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 parameterless, read-only listing tool with no output schema, the description is complete: it defines the permission scope, when to call it, how to format the result, and the ending behavior. An agent can invoke and present results correctly from this text alone.

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 schema has zero parameters, so the baseline is 4; there is no parameter meaning for the description to clarify. The description instead clarifies the output presentation, which is the relevant semantic gap.

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

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

The description opens with 'Ação somente leitura: mostra quais pastas você pode acessar agora', a specific verb and resource plus an access-scope qualifier. This makes it accurately distinguishable from siblings like listar_arquivos (files) and solicitar_acesso_pasta (requesting access).

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: 'Use quando o usuário perguntar o que você consegue acessar.' It does not mention exclusions or alternative tools, but the context is clear enough for an agent to select it appropriately.

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

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

Beyond the annotations (readOnly=false, destructive=false), the description exposes the default conflict error behavior, the rename strategy with an example, the non-destructive nature of the move, and the requirement to keep operations within authorized folders. It also instructs the agent not to decide conflicts autonomously.

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

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

The description is front-loaded with the core operation and constraint, then details conflict behavior and user interaction. The included user-facing script example is useful but makes it slightly longer than strictly necessary.

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 output schema, the description covers operation, constraints, conflict handling, and required user communication. It doesn't specify the return format or error behavior for unauthorized paths, but those are not critical for an agent to invoke it correctly.

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

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

Schema covers all three parameters, so baseline is 3. The description adds value by explaining the default conflict behavior and illustrating the 'rename' strategy with 'arquivo (2).pdf', which is not in the schema.

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

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

The description uses a specific verb ('Move') and resource ('arquivo ou pasta'), and clarifies the scope ('sempre dentro de pastas autorizadas'). It is clearly distinct from siblings like copiar_item or renomear_item, though it does not explicitly name them.

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 pre-call and post-call guidance: explain to the user what will be moved, where it will go, that the file will persist, and confirm after moving. It also instructs the agent to ask the user on name conflicts. However, it does not explicitly state when to prefer this tool over copiar_item or renomear_item.

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 destructiveHint=false, and the description reinforces this with 'somente leitura' and 'sem alterar seu conteúdo'. It adds valuable behavioral guidance beyond the annotations: no confirmation is needed and the assistant should describe the result in simple terms without citing the technical tool 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?

The description is three dense sentences with no filler. It front-loads the read-only nature, then lists returned metadata fields, and closes with concrete user-interaction instructions. 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 simple one-parameter, read-only tool with full schema coverage and supporting annotations, the description is complete. It covers what the tool does, what it returns, that it is non-destructive, that confirmation is not needed, and how to communicate the result to the user.

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 input schema already covers the only parameter, 'caminho', with 100% description coverage. The tool description does not add extra parameter-level semantics such as supported path formats or whether the path can be relative or absolute, so it remains at the baseline for fully documented schemas.

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 identifies the operation as a read-only metadata query for a file or folder, enumerating the exact data returned (name, extension, type, size, creation/modification dates). It explicitly states the content is not altered, which differentiates it from sibling mutation tools like mover_item, renomear_item, and enviar_para_lixeira.

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 provides clear context: use this when the user needs file/folder information without changing anything, and no confirmation is required. It does not explicitly compare against sibling tools like listar_arquivos or buscar_arquivos, so it stops short of giving exclusions or alternative routing.

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

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

Beyond the annotations, the description discloses meaningful behavior: no silent operations, an item-by-item report of success/failure/conflict, shared safety/conflict validation with mover_item, explicit reassurance that no file is deleted, and required user-facing pre/post steps. This is substantial transparency for a 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?

The description is longer than a simple tool's but every sentence earns its place: core behavior first, then safety/reporting, then workflow instructions, then user-communication constraints. It is front-loaded and dense without redundancy.

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 compensates by specifying the item-by-item report containing success, failure, or conflict. It also covers authorization limits, batch size, conflict behavior consistency with mover_item, preview workflow, and post-execution reporting, making the tool fully actionable.

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 schema documents operacoes with min/max and structure, and the description adds that origem/destino must be inside authorized folders. However, conflictStrategy is left without explanation beyond the enum values and default; the description mentions conflict validation generically but does not clarify the 'error' versus 'rename' behavioral difference.

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

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

The description opens with a precise action: 'Move vários arquivos/pastas de uma vez', and immediately defines the batch scope and per-operation source/destination structure. It clearly distinguishes itself from the singular mover_item sibling by emphasizing multiplicity and up to 100 operations per call.

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

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

The description gives clear operational context: use this for batch moves, each operation goes through the same validations as mover_item, and preparar_acao is recommended as a non-mutating preview step before executing. It does not explicitly name exclusions or say 'use mover_item for a single move', but the batch framing makes the intended use sufficiently 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 mark this as non-read-only and non-destructive. The description adds meaningful behavioral context beyond that: it explicitly states the tool modifies only the name and/or destination folder, and it requires the agent to show the current rule name and explain changes before executing. This is a valuable user-facing behavior not captured by the annotations or schema.

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 concise sentences, with the core function front-loaded and no filler. The first sentence states the operation and scope; the second provides a necessary interaction requirement. Every word 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?

The description covers the primary operation and a key confirmation behavior, and the schema handles the required id. But with no output schema, no mention of what the tool returns, and no guidance on how to obtain/format the destination folder, the context is incomplete for an agent that needs to call this correctly on the first try. The missing at-least-one-field requirement is also a notable 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 only 33% (only 'id' is documented), so the description must compensate for novo_nome and nova_pasta_destino. It partially does this by mapping them to 'nome' and 'pasta de destino', which gives basic semantic meaning. However, it does not clarify the expected format for nova_pasta_destino (folder name vs. folder ID) or indicate that at least one of the optional fields must be supplied, leaving meaningful ambiguity.

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

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

The description uses a specific verb 'Altera' with a clear resource ('regra existente') and delimits the exact scope: name and/or destination folder. This distinguishes it from sibling tools like outlook_criar_regra, outlook_ativar_regra, and outlook_excluir_regra, so an agent can immediately identify what this tool does and does not do.

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 the tool is for modifying an existing rule, and the schema notes the id comes from outlook_listar_regras, which gives some context. However, there is no explicit statement about when to choose this tool over alternatives, nor exclusions such as 'do not use for creating or activating rules'. The 'mostre o nome atual' instruction is a behavioral step, not a usage-selection guideline.

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

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

The description adds genuine behavioral value beyond the annotations: it states the email remains available, says it only leaves the Inbox, and explicitly says it is not deletion. It also requires the agent to warn the user before executing, which is a useful safety guardrail not expressed in the structured metadata.

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 short sentences, front-loads the core action first, then adds the non-deletion clarification and the user-warning instruction. Every sentence earns its place with no redundancy.

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 single-parameter action with no output schema, the description covers all essential context: the destination folder, the non-destructive nature, and the required user interaction. No critical information 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?

The only parameter, id, is fully covered by the schema with 'ID do email.' The description adds no extra meaning about the ID's format, scope, or validity, so the schema carries the burden and 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 clearly states a specific action — moving an email to the Archive (Arquivo Morto) folder — and explicitly distinguishes this from deletion. It does not explicitly contrast itself with the sibling outlook_mover_email, so it stops short of full sibling differentiation.

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

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

The description makes the use case clear: use it when the intent is to archive, and clarifies it is not for deletion. It also provides a direct operational guideline to warn the user before executing, but it does not mention when to use the plural variant outlook_arquivar_emails or outlook_mover_email as alternatives.

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

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

Annotations already indicate destructiveHint=false, but the description adds useful behavioral context: emails remain available after archiving and leave the Inbox. It also discloses the required user-communication step, which is not inferable from annotations or schema.

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

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

The description is compact and front-loaded with the action and limit. The quoted example in the second sentence is slightly redundant but earns its place by specifying exactly what the agent must say before executing.

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 batch operation with no output schema, the description covers the action, batch limit, non-destructive nature, and a required pre-execution message. It is sufficient for correct invocation, though it does not mention connection or account prerequisites.

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% since the ids parameter is described as 'IDs dos emails. Máximo 50.' The description mostly restates the batch size and does not add new parameter-level meaning such as ID format, source requirement, or how to obtain valid IDs.

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

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

The description states a specific verb and resource: 'Move vários emails para o Arquivo Morto de uma vez (até 50).' It clearly scopes the operation as batch archiving and explicitly distinguishes it from deletion, which also separates it from the singular sibling tool outlook_arquivar_email.

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 provides a clear usage instruction: 'Antes de executar, informe a quantidade,' and clarifies this is archival, not deletion. However, it does not explicitly name alternatives or give exclusion criteria such as when to use outlook_mover_emails or outlook_arquivar_email instead.

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 indicate the operation is not read-only ('readOnlyHint': false), not destructive, and idempotent. The description adds the contextual detail that the rule was disabled, which is helpful. It does not describe side effects or prerequisites, but for a simple activation tool the annotations carry enough of the behavioral burden.

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 communicates the action, the resource type, and the target state with no filler. Every word earns its place and the description is immediately parseable.

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 clearly documented parameter and annotations covering safety and idempotency, the description is essentially complete. It could mention how to obtain the rule ID or what happens if the rule is already active, but those are minor gaps for such a simple operation.

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 schema already fully documents the only parameter ('id' as 'ID da regra') with 100% coverage. The description adds no additional meaning about the parameter, so the baseline score of 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?

The description clearly states the action ('Reativa') and the resource ('uma regra da Caixa de Entrada'), and specifically scopes it to rules that were previously disabled. This differentiates it from related sibling tools like outlook_desativar_regra, outlook_criar_regra, and outlook_excluir_regra without needing to inspect their schemas.

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 'que estava desativada' gives clear context for when to use the tool: when a rule has been disabled and needs to be re-enabled. It does not explicitly name an alternative tool or state when not to use it, but the intended usage is evident and the complement (outlook_desativar_regra) is identifiable from the sibling list.

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

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

The description goes well beyond the annotations by explaining that local Outlook text search reads only a limited batch and that the response indicates when it was not exhaustive, whereas Microsoft 365 search always runs server-side. It also explicitly states 'Não altera nada', reinforcing the readOnlyHint and adding valuable operational context.

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

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

The description is well-structured and front-loads the read-only nature, then lists search dimensions, gives performance advice, and mentions the alternative tool. It is slightly longer than strictly necessary since 'Ação somente leitura' and 'Não altera nada' are somewhat redundant, but every substantive detail 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 tool with 10 optional parameters and no output schema, the description covers the main usage dimensions, environment-dependent behavior, non-exhaustive search caveats, and follow-up actions. It does not describe the exact return format or how results are structured, which would be helpful given there is no output schema, but the essential calling context is 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?

The description enriches parameter meaning by clarifying that 'texto' covers subject plus body, that folder search includes trash/deleted items, and that filters can be combined. Schema coverage is 70%, and some parameters like 'nao_lido' and 'limite' are not described anywhere, but the description adds useful semantics for the most important filtering dimensions.

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 a read-only email search tool with specific filter dimensions: sender, domain, subject, free text, date, attachment, and folder, including deleted items. It is easy to understand what the tool does, but it does not explicitly differentiate itself from the sibling 'outlook_listar_emails', relying on the tool name to carry that distinction.

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

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

The description gives clear usage context: combine filters before text search for speed, and use results for batch organization or 'outlook_ler_email' for reading a single full message. It does not explicitly say when to avoid this tool or when to prefer 'outlook_listar_emails', but it does provide a concrete alternative for follow-up actions.

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

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

The description adds substantial behavioral detail beyond annotations: it opens the user's browser, waits for interaction, supports MFA and organization policies, and even instructs how to phrase the action to the user (avoiding OAuth/MSAL terminology). It complements the openWorldHint rather than contradicting it, and there is no annotation contradiction.

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

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

The description is two tight sentences: the first front-loads the core behavior, and the second provides the usage condition and user-facing guidance. Every clause earns its place, and no redundant or filler text is present.

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

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

For an authentication/connection tool, the description is complete: it says what it does, when to invoke it, what the user will experience, and how to describe the action to the user. No output schema is needed, and the tool's side-effectful nature is clearly communicated via description and annotations together.

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 has zero parameters, so the baseline of 4 applies. There are no parameter semantics to clarify, and the description does not need to compensate for any schema coverage gap. A 5 would require it to add value where there is nothing to add.

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

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

The description opens with a specific verb and resource: 'Inicia a conexão com o Outlook/Microsoft 365 do usuário' and details the concrete action of opening the Windows default browser for Microsoft login. It clearly distinguishes this connection/setup tool from the many Outlook action siblings and from outlook_status/outlook_desconectar.

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

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

It explicitly states when to use the tool: 'Use quando o usuário pedir algo do Outlook e outlook_status disser que ainda não está conectado.' This provides a clear decision rule and references the relevant sibling tool. It does not explicitly name when-not-to-use cases or alternatives, though the condition strongly implies them, so it falls just short of a perfect 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?

Beyond the annotations, the description adds valuable behavioral context: it instructs the agent to announce the folder before creating it and confirm afterwards, and it explicitly states 'Não afeta nenhum email existente.' It does not cover duplicate-name or failure behavior, but the annotations plus this safety statement give a good transparency profile.

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

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

The description is compact and well-structured: the purpose comes first, followed by user-interaction steps and a safety note. Each sentence earns its place with no redundancy or 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 one-parameter create tool with no output schema and no nested objects, the description is nearly complete: it covers purpose, required user communication, and non-destructive behavior. It does not address preconditions such as an active Outlook connection or duplicate folder handling, but these are not critical at this complexity level.

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

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

Schema coverage is 100%: the single parameter 'nome' is already described as 'Nome da nova pasta.' The tool description does not add new parameter-level detail beyond reinforcing that this name will be communicated to the user, so the schema carries the semantic burden and the baseline of 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 opens with 'Cria uma pasta de email' – a specific verb and resource that clearly identifies a create operation for an Outlook email folder. The explicit 'Outlook' reference and example distinguish it from the generic sibling 'criar_pasta'.

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 intended context (creating a new email folder in Outlook) is clear, but the description does not explicitly contrast with alternatives such as outlook_listar_pastas, outlook_mover_email, or generic criar_pasta. Usage is implied rather than stated with when-to-use or when-not-to-use guidance.

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

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

Annotations already indicate mutation (readOnlyHint=false) and non-idempotence, and the description adds crucial context: it never sends emails to third parties, it requires explicit user confirmation, it applies only to future messages, and it must not be auto-retried on failure. No contradiction with 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?

Front-loaded with the core action, followed by high-value guardrails: no forwarding, confirmation protocol, existing-emails alternative, and failure handling. Every sentence contributes operational or safety-relevant guidance; 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?

Given a mutating tool with no output schema, the description covers prerequisites (confirmation), scope (future emails), exclusions (no forwarding), failure behavior (no retry, diagnostic tool), and sibling differentiation. An agent has what it needs to invoke this tool safely and correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented structurally. The description reinforces the role of condition fields and destination folder, but adds no extra per-parameter constraints, formats, or examples beyond the schema. 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?

Description uses a specific verb and resource: 'Cria uma regra' for automatically moving future matching emails to a folder. It explicitly distinguishes from forwarding rules ('NÃO cria regras de encaminhamento') and from organizing existing emails, so an agent can clearly identify what this tool does and what it does not do.

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 explicit when-to-use criteria: only for future emails with simple sender/subject conditions. It names the alternative outlook_mover_emails for existing emails, mandates confirmation before running, and specifies using outlook_diagnostico_ultima_falha on failure. This is unusually rich 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?

As anotações já informam idempotentHint=true e destructiveHint=false, e a descrição acrescenta contexto comportamental relevante: a regra para de rodar, mas permanece persistida. Não há contradição com as anotações, e o efeito concreto da operação fica claro.

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?

Uma única frase transmite a ação, o escopo e o resultado não destrutivo, sem excessos. A informação essencial vem no início, e cada parte contribui para o entendimento do agente.

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?

Para uma ferramenta simples, com apenas um parâmetro e sem output schema, a descrição é suficiente: diz o que acontece, o que não acontece e o estado final da regra. Não falta contexto necessário para invocar corretamente.

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?

A cobertura do schema é 100%: o único parâmetro obrigatório 'id' já está documentado como 'ID da regra'. A descrição não adiciona nem precisa adicionar detalhes além do que o schema já fornece, então o baseline 3 é adequado.

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?

A descrição usa verbo específico ('Desativa') e identifica o recurso ('regra da Caixa de Entrada'), esclarecendo a ação central. A frase 'sem excluí-la' diferencia claramente de outlook_excluir_regra e outlook_ativar_regra, sem exigir que o agente abra outros schemas.

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?

O texto indica o contexto de uso: desativar uma regra mantendo-a salva, em oposição a excluí-la. Embora não nomeie explicitamente alternativas ou diga 'use X em vez de Y', a informação 'sem excluí-la — ela para de rodar, mas continua salva' estabelece um critério claro de escolha.

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 mark this as destructive and idempotent, but the description adds valuable context: it deletes the saved login locally, does not revoke organization consent, and always requires human confirmation before execution. This goes well beyond the annotation hints.

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 compact sentence with the destructive warning front-loaded and no filler. Every clause adds meaningful information: scope, effect, non-effect, and confirmation requirement.

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 local logout action with no output schema, the description fully covers what happens, what does not happen, and the required consent gate. Nothing necessary for an agent to decide whether and how to invoke the tool 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 for the single optional parameter is 100%, and the parameter's own description already explains that it is for internal testing and normally not needed. The tool description adds no additional parameter semantics, so the baseline of 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 uses a specific verb and resource: it 'apaga o login salvo do Outlook nesta extensão', which clearly identifies what is deleted and where. It also explicitly distinguishes the tool from org-level revocation, so an agent can tell it apart from other Outlook tools like outlook_conectar.

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 makes the usage context clear: this is a local disconnect, not a revocation of organizational consent. It implies when not to use it (when the goal is to revoke consent) and states the required human confirmation, though it does not name an alternative tool explicitly.

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

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

The description reinforces the readOnly and idempotent annotations by saying 'sem alterar nada', and adds meaningful behavioral context: it performs a step-by-step diagnostic covering COM, MAPI, and discovered accounts. It does not describe the output format, but annotations already establish the safety profile, so the bar is lower.

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 with no wasted content: the first front-loads the read-only diagnostic nature and target, the second gives concrete trigger conditions, and the third prevents misuse by directing normal use to outlook_status.

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 investigative tool, the description fully covers when to invoke it, what it checks, and that it is safe. The output schema is absent, but the description's outcome framing ('verifica passo a passo se...está acessível') is sufficient for an agent to select and call it correctly.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify about arguments. Baseline 4 is appropriate because no parameter semantics 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 opens with 'Ação somente leitura' and a specific verb, 'verifica passo a passo se o Outlook Clássico deste computador está acessível (COM, MAPI, contas encontradas)', which names both the resource and the diagnostic scope. It also distinguishes itself from sibling diagnostics like outlook_status by defining its role as troubleshooting a failed local access.

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

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

It gives explicit usage conditions: use when 'outlook_status disser que não conseguiu acessar o Outlook local e o usuário quiser entender por quê', or when technical details are requested. It also states the exclusion explicitly: 'Para uso normal, prefira outlook_status — esta tool é para investigar um problema.'

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?

A descrição vai além das anotações ao explicar o comportamento de resolução do nome e listar os quatro desfechos possíveis. As anotações já declaram readOnlyHint e idempotentHint, e o texto confirma a natureza somente leitura; falta apenas detalhar o formato exato da resposta, mas isso é parcialmente compensado pela enumeração dos resultados.

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 descrição é composta por duas frases diretas, com a informação mais importante ('Ação somente leitura') no início. Cada frase adiciona valor: a primeira define o comportamento e os resultados; a segunda define a condição de uso. Não há redundância.

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?

Para uma ferramenta somente leitura, com parâmetros totalmente documentados no schema e anotações de segurança, a descrição entrega o contexto necessário: o escopo da resolução e os resultados esperados. Poderia ser um pouco mais explícita sobre a ausência de efeitos colaterais, mas as anotações já cobrem isso, então a definição é suficientemente completa.

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?

O schema já cobre 100% dos parâmetros com descrições, então a baseline é 3. A descrição acrescenta significado ao explicar que o valor é um 'nome de pasta (padrão ou personalizada)' informado pelo usuário, o que contextualiza o parâmetro 'valor' e reforça o papel do parâmetro '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?

A descrição identifica com precisão o que a ferramenta faz: mostrar como o Outlook local resolveria um nome de pasta, incluindo os resultados possíveis (semântico, por nome, ambíguo, não encontrado). Isso a distingue claramente das ferramentas irmãs de diagnóstico, como outlook_diagnostico_ultima_falha, e de listagem, como outlook_listar_pastas.

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?

A frase 'Use apenas quando o usuário pedir detalhes técnicos sobre por que uma pasta não foi encontrada' é uma instrução explícita de quando acionar a ferramenta. O 'apenas' estabelece também um limite claro, evitando uso para listagem ou manipulação de pastas.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, and the description reinforces that with 'somente leitura' and 'Não altera nada'. It adds valuable safety context by guaranteeing the tool 'não contém corpo de email, senha ou token', which is useful privacy information 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 efficiently packed sentences: the first establishes the read-only nature, exact resource, and returned fields; the second provides usage triggers, a default-behavior prohibition, and a data-safety guarantee. Every clause earns its place with no redundancy.

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, no-output-schema diagnostic tool, the description is complete: it names the resource, the session scope, the returned data fields, the usage trigger, the prohibition on default display, and the absence of sensitive content. An agent has everything needed to select and invoke it correctly.

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

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

The tool has zero parameters, so parameter semantics are not applicable; per the baseline for 0 params, this scores 4. The description compensates by explaining the return fields, which effectively clarifies what the agent should expect despite the lack of an output schema.

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

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

The description states a specific verb ('retorna') and resource ('a última falha registrada em uma ação do Outlook Local nesta sessão do servidor'), and enumerates the exact returned contents: stage, mensagem técnica, and estado de conexão. This clearly differentiates it from generic status or resolution diagnostics among the siblings.

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

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

The description explicitly says when to use it ('quando o usuário pedir detalhes técnicos, em que stage falhou ou algo assim') and provides a firm when-not rule ('nunca mostre esses detalhes por padrão numa resposta normal'). It does not name alternative sibling tools such as outlook_diagnostico_local or outlook_diagnostico_resolucao, so it stops short of a full alternatives comparison.

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 mark destructiveHint=true and readOnlyHint=false, and the description adds substantial behavioral context: it clarifies this is never permanent deletion, states that no permanent-delete tool exists, discloses that the tool itself requests human confirmation, and explains the id_atual refresh behavior after a move. This goes well beyond the annotation data and directly helps the agent avoid dangerous misuse.

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 longer than average, but it is appropriately front-loaded with 'AÇÃO DESTRUTIVA' and uses a clear numbered list for mandatory steps. Every sentence contributes safety or workflow information, so the length is justified; it still feels dense but not 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 destructive, multi-step tool with no output schema, this description is remarkably complete. It covers confirmation requirements, recoverability, the absence of permanent-deletion tooling, and even the special case of reusing a returned id_atual. The agent has everything needed to invoke it correctly and safely.

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?

Although the schema covers 100% of the one parameter ('ids'), the description adds crucial semantics: it relates the ids to the number of emails to disclose, and it tells the agent to use the id_atual returned by a prior move operation instead of the old id. This is exactly the kind of parameter meaning that the schema alone cannot convey.

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 the specific action: 'move um ou mais emails para Itens Excluídos' and explicitly distinguishes this from permanent deletion. However, it does not differentiate itself from sibling move tools like outlook_mover_email or outlook_mover_emails, so the agent must infer the unique destination is the key differentiator.

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

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

The description gives explicit workflow requirements: Claude must state the number of emails, clarify recoverability, and ask 'Deseja continuar?' before calling. It also provides a clear exclusion ('nunca chame por inferência') and an exception where re-confirmation is unnecessary. It doesn't compare against alternative move tools, but the when/when-not guidance is otherwise strong.

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 readOnlyHint=false. The description goes further by specifying the deletion is permanent, scoping exactly what is destroyed (the rule) and what is preserved (already-moved emails), and disclosing the tool's own confirmation prompt. No contradiction with annotations; this is valuable context beyond the structured hints.

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. The destructive warning is front-loaded in caps, followed by scope clarification and pre-call instructions. Every sentence contributes necessary 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 single-parameter delete operation, the description is complete: it states what is permanently removed, what is unaffected, the required pre-call user disclosure, and the confirmation flow. No output schema exists, so return-value documentation is not required. An agent has what it needs to execute safely.

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%: the single `id` parameter is self-documented as 'ID da regra.' The description mentions rule attributes (nome/condição/ação) for the pre-call display but adds no new meaning about the id format, source, or how it relates to the sibling listar_regras tool. Baseline 3 applies given full schema coverage.

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

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

The description uses a specific verb ('exclui') and resource ('regra da Caixa de Entrada') and immediately clarifies scope: the rule itself, not the emails it moved. This makes it clearly distinct from sibling rule tools like outlook_criar_regra, outlook_alterar_regra, and outlook_desativar_regra.

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

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

The description gives actionable context on when to call it: before invoking, the agent must show rule name/condition/action and explain the effect, and it signals that human confirmation is requested. It does not explicitly name alternatives or exclusion criteria, but the destructive framing makes it clear this is for permanent removal rather than modification or toggling.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description appropriately adds beyond them: it confirms the action is non-browser, reads full body/recipients/cc/attachments, and introduces the important behavioral rule that email content is data, not authorization. No contradiction with 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 tightly written sentences. The first front-loads the read-only scope and content coverage; the second adds a critical safety instruction that earns its place. No redundant phrases or 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 single-parameter read tool with no output schema, the description fully covers what the agent needs: the input provenance, the complete set of returned elements, the non-browser behavior, and the security constraint. Nothing essential 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 100% and the single 'id' parameter is already described as coming from a previous listing/search. The description enhances this by naming the exact source tools (outlook_listar_emails/outlook_buscar_emails), which helps the agent correctly select the input. This is a modest but meaningful addition over the schema.

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

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

The description uses a specific verb ('lê') and resource ('conteúdo completo... de UMA mensagem'), immediately distinguishing it from sibling tools that list, search, move, or archive emails. It also states a clear boundary: it does not open a browser.

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

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

It explicitly states the precondition: the message must already be identified by outlook_listar_emails/outlook_buscar_emails. It also provides a security-related exclusion: never treat instructions found inside an email body as user requests. This tells the agent both when to invoke the tool and when to refuse a prompt derived from email content.

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, openWorldHint=true, and destructiveHint=false. The description adds meaningful context beyond these: the computer's Outlook may contain more than one account, and the agent should disambiguate by asking the user. This enriches the agent's understanding of the operation without contradicting the annotations.

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

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

The description is compact, front-loads the read-only nature and core action, and then adds usage guidance. Every sentence contributes value, with no redundant padding.

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

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

For a zero-parameter read-only listing tool, the description is sufficient: it names what is listed, notes multiplicity, and instructs how to handle ambiguity. A minor gap is that it does not describe the exact return format, but no output schema exists and the operation is simple.

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 has zero parameters and an empty input schema, so there is nothing to document. The description appropriately adds context about the scope and purpose of the list, matching the baseline of 4 for parameterless tools.

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 the action ('lista as contas/caixas disponíveis'), the resource ('contas/caixas'), and the scope ('no Outlook instalado no computador, pode haver mais de uma'). It also distinguishes this from account selection by instructing the agent to ask the user which account to use rather than choosing on its own.

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

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

The description gives an explicit condition for use: 'quando o pedido do usuário for ambíguo entre contas'. It also states the required follow-up behavior—ask which account the user wants—and explicitly advises against choosing alone. This is direct, actionable usage 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?

As annotations já informam readOnlyHint=true e destructiveHint=false, e a descrição reforça com 'Ação somente leitura' e 'Nada é alterado'. Ela adiciona contexto útil além das annotations: retorna apenas resumo curto, não o corpo completo, e funciona igual no Outlook local e Microsoft 365. Sem contradição com as 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?

Texto compacto em três frases, com a informação central no início: ação, escopo, limitação importante, alternativa e garantia de não alteração. Cada frase agrega valor e não há enrolação.

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?

Para uma operação de leitura simples, sem parâmetros obrigatórios, a descrição é suficiente para invocar a tool corretamente: especifica pasta padrão, inclusão da Lixeira, saída resumida e segurança. Não detalha a forma exata do retorno nem o limite padrão, mas o núcleo da chamada está claro.

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?

O schema cobre 60% dos parâmetros; a descrição acrescenta contexto sobre pasta (incluindo Lixeira e padrão Caixa de Entrada) e sobre a noção de 'recentes', mas não explica diretamente 'limite' ou 'somente_nao_lidos'. Os nomes dos parâmetros são relativamente autoevidentes, então é adequado, mas não completo.

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?

A descrição define claramente a ação ('lista os emails mais recentes de uma pasta'), o escopo (pasta, incluindo Lixeira, padrão Caixa de Entrada) e o que não faz ('não retorna o corpo completo'). Também diferencia de um sibling ao indicar outlook_ler_email para leitura do conteúdo completo.

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?

A descrição diz claramente quando usar a ferramenta — listar resumos de emails recentes — e indica explicitamente a alternativa para o caso de se precisar do conteúdo completo ('use outlook_ler_email para ler uma mensagem específica por inteiro'). Isso funciona como uma condição de quando não usar esta 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 destructiveHint=false, and the description's 'Nada é alterado' reinforces that. It adds useful output details ('nome e quantidade de itens') but does not go beyond annotations regarding side effects or system behavior. No contradiction with 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?

One short sentence that front-loads the read-only nature and then states the resource and return contents. Every word earns its place; there is no redundancy.

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 listing tool with no output schema, the description provides all essential information: what is listed, whose data it is, that it is non-destructive, and what fields are returned. Nothing necessary for correct invocation 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?

The tool has zero parameters and the schema defines no properties, so there is nothing for the description to clarify. The baseline of 4 applies because parameter semantics are trivially complete without needing 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 uses a specific verb ('lista') and a clear resource ('as pastas de email do usuário'), and it explicitly states what is returned (nome e quantidade de itens). This clearly distinguishes it from sibling tools like outlook_listar_emails or listar_arquivos.

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 context is clear: use this to list the user's email folders. However, there is no explicit guidance about when not to use it or which alternative to choose, such as outlook_listar_emails for messages or listar_arquivos for files. The usage 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?

As anotações já declaram readOnlyHint e destructiveHint, e a descrição reforça o comportamento sem contradição. Ela agrega valor ao detalhar os campos retornados e o escopo 'Caixa de Entrada', o que ajuda o agente a entender o resultado da chamada.

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?

Uma única frase direta, com a informação essencial ('somente leitura') posicionada no início e o restante organizado de forma compacta. Não há palavras redundantes.

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?

Para uma ferramenta sem parâmetros, com anotações de segurança já fornecidas e sem schema de saída, a descrição é suficiente: informa o que lista, o escopo e os campos retornados. Nada essencial para chamar a ferramenta corretamente está faltando.

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?

A ferramenta não possui parâmetros, então o baseline é 4. A descrição não precisa explicar parâmetros e corretamente foca no que a operação retorna.

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?

A descrição usa verbo específico ('lista'), identifica o recurso ('regras automáticas configuradas na Caixa de Entrada') e especifica o conteúdo retornado (nome, condição, ação, ativa). Isso diferencia claramente a ferramenta dos irmãos que criam, alteram, ativam, desativam ou excluem regras.

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?

A descrição deixa claro o contexto de uso: operação somente leitura para listar regras existentes. Não menciona explicitamente alternativas ou exclusões, mas o contexto e os nomes dos irmãos tornam óbvio quando usar esta ferramenta em vez das outras ações de regras.

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?

It discloses important non-obvious behaviors beyond the annotations: the email leaves the current folder but is not deleted, its ID may change after the move, and subsequent actions must use the returned id_atual instead of the old ID. This materially changes how an agent should chain follow-up calls.

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 concise and front-loaded with the core action. The embedded user-facing script adds length but is justified because it specifies the required pre-execution announcement and reinforces the side-effect expectation. No filler or redundant restatement.

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 tool with safety annotations already present, the description covers the action, side effects, return identifier, and follow-up behavior. Even without an output schema, the essential id_atual contract is clearly stated.

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 the baseline is 3. The description adds meaningful semantic detail for the id parameter: it comes from a prior listing/search and may change after moving, requiring the returned id_atual for later actions. This is genuinely useful 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?

The description clearly states a specific action and resource: moving one email to another folder ('Move um email para outra pasta'). It is not a tautology and the singular 'um email' hints at scope, but it does not explicitly differentiate itself from siblings like outlook_mover_emails or mover_item.

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

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

The description gives clear execution guidance: announce which email is being moved and the destination before acting, and use the returned id_atual for any follow-up actions. It provides clear context but does not explicitly say when to prefer this tool over alternatives such as outlook_arquivar_email or outlook_mover_emails.

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

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

Beyond the annotations, which already mark it as non-read-only and non-destructive, the description adds a per-item success/failure report, the 50-item cap, and the crucial note that returned `itens` contain new `id_atual` values that must be used instead of old IDs in subsequent actions. It also clarifies that no email will be deleted, matching the destructiveHint.

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

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

The description is compact: three sentences with the purpose front-loaded and each sentence providing a distinct operational detail. The included user-facing example adds a little length but supports the workflow requirement.

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 batch mutation tool with no output schema, it covers cap, destination scope, return report format, a helper alternative, and post-move ID semantics. It does not detail behavior for partial failures or inputs exceeding 50, but the report and cap make those reasonably inferable.

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 parameters are already well-documented. The description largely repeats the batch limit for `ids` and the destination concept for `pasta_destino`; the valuable `id_atual` note pertains to output behavior rather than input parameter semantics.

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

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

The description states a specific batch operation: moving multiple emails at once (up to 50) to the same destination folder. It clearly distinguishes itself from the singular sibling outlook_mover_email through the plural 'vários' and the explicit batch limit.

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

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

The description gives clear context for when to use the tool: batch-moving up to 50 emails to a common destination, and explicitly suggests using outlook_preparar_acao beforehand. It does not explicitly mention singular alternatives or when not to use it, but the batch scope and helper pointer are enough for an agent to route correctly.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false; the description reinforces that no email is changed and adds concrete behavior: validation, counting affected items, and generating a Portuguese explanation. It does not describe edge cases or error behavior, but the extra context is meaningful.

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 punchy sentences front-load the read-only behavior and core purpose, with no filler. Every clause earns its place, and the emphatic 'NÃO altera nenhum email' is a useful guardrail.

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 small preview tool with complete parameter schemas and safety annotations, the description covers what it does, when to use it, and what it returns (a Portuguese explanation to show the user). The lack of an output schema is partly compensated by the description's explicit statement that it mounts the explanation; still, error/validation failure behavior is unspecified.

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

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

Schema description coverage is 100%, so the baseline is 3 even without extra parameter details. The description loosely maps to parameters by mentioning 'seleção de emails' (ids) and 'pasta de destino' (destino), but it adds little beyond the already complete schema, and it omits the 'itens_excluidos' action from its prose.

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 validates an email selection and destination folder, counts affected items, and builds a Portuguese explanation before batch move/archive or rule creation. It clearly separates this preview tool from mutating siblings by emphasizing 'somente leitura' and 'NÃO altera nenhum email'.

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 when to use the tool: before moving/archiving in batch or creating a rule, and says the generated explanation must be shown to the user. However, it does not explicitly name alternatives or state when not to use it beyond the implicit read-only contrast with execution 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 provide idempotentHint, destructiveHint, and readOnlyHint background. The description adds the key stateful trait: the selection is session-only and changes no permanent configuration. This is valuable context beyond what annotations convey, with no contradiction.

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

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

Two tight sentences: the first states the core selection behavior and when it applies, the second clarifies the session-scoped, non-persistent nature. Every sentence adds necessary information with 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 selector, the description covers the purpose, the triggering condition, where to get the ID, and the scope of the effect. The annotations handle safety/idempotency, and no output schema is needed for a state-selection 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 100%, and the schema's 'id' description already explains that it comes from outlook_listar_contas. The description merely reinforces that source without adding new parameter semantics, so the 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 uses a specific verb ('Define') and resource ('qual conta/caixa usar') and narrows the scope to 'próximas ações desta conversa'. It clearly differentiates this selection tool from outlook_listar_contas and other Outlook action tools by explaining its role.

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 when-to-use condition: 'quando houver mais de uma disponível', and points to outlook_listar_contas for available accounts. It does not explicitly contrast with alternative tools like outlook_conectar or state when not to use it, so it falls just short of full 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent. It adds useful behavioral context: no sensitive data is exposed, only what the server can verify directly, and it cannot detect the integrated browser or Claude in Chrome. It also adds a user-facing constraint about not mentioning COM, OAuth, MSAL, or Graph.

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 dense but front-loaded with the read-only status purpose before limitations and instructions. Every sentence carries useful guidance, though the third sentence is long and packs in multiple conditions, making it slightly harder to parse quickly.

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 partially documents return fields and gives a fallback action when Outlook is unavailable. It does not enumerate every possible value of `proxima_opcao`, but for a simple status-check tool the agent has enough context to invoke and interpret it correctly.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to document; instead, the description adds meaning by mentioning the expected output concepts `disponivel` and `proxima_opcao`, which helps an agent interpret the result.

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

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

The description opens with 'Ação somente leitura' and clearly says the tool reports whether the agent can work with Outlook now and via which route (local install or Microsoft 365 account). This is a specific verb, resource, and scope, and it is clearly distinct from mutating Outlook siblings and file-related 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 explicitly says to use it before an Outlook action when unsure ('Use antes de uma ação de Outlook se não tiver certeza'). It also provides branch guidance for when `disponivel=false` and `proxima_opcao` points to a browser, telling the agent to follow server instructions for alternatives.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces those. It adds meaningful behavioral context: the tool builds a user-facing explanation, the field requer_confirmacao signals when to ask the user, and the agent must never reveal technical tool names.

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 dense sentences, each earning its place: the first states the core purpose, the second gives usage and a worked example, the third defines the confirmation rule. Nothing is redundant or 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?

Given the absence of an output schema, the description covers when to use the tool, what it returns conceptually (validation and plain-Portuguese explanation), and highlights the key output field requer_confirmacao. It could have detailed the full return shape, but the essential guidance is 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 coverage is 100%, with each parameter already described. The description adds no new parameter-level semantics beyond an illustrative example; baseline 3 is appropriate since the schema does the heavy lifting.

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 ('valida e explica'), a specific resource ('ação de arquivos'), and explicitly declares the read-only scope ('SEM alterar nada no disco'). It names the sibling execution tools it precedes, so an agent can distinguish it from them.

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

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

It explicitly says to use this tool before mover_item, copiar_item, renomear_item, criar_pasta, organizar_arquivos, or enviar_para_lixeira, and explains when to require confirmation (conflitos de nome e envio para a Lixeira). It also provides a concrete example of the output and instructs how to communicate with the user.

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 carry no positive hints (readOnly=false, destructive=false), so the description bears the responsibility for disclosing behavior. It clearly states that the item stays in the same folder, content is unchanged, and Windows-invalid characters are forbidden. It stops short of covering overwrite/conflict behavior and error cases, but the main behavioral traits are well disclosed.

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?

Every sentence earns its place: the core action, the same-folder constraint, the naming constraints, and the user-communication protocol. The content is front-loaded and free of filler, making the instructions easy to parse and apply.

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 rename tool with two well-documented parameters, the description is largely complete: it covers behavior, constraints, and expected agent interaction. Minor gaps remain around return/result semantics, overwrite conflicts, and error handling, but these do not seriously hinder correct invocation.

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

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

Schema coverage is 100%, giving a baseline of 3. The description adds real semantic value for novo_nome by specifying that it must be only a name without slashes or path components and must avoid Windows-invalid characters. This goes beyond the schema's brief description without contradicting it.

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

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

The description opens with a specific verb and resource ('Renomeia um arquivo ou pasta') and explicitly scopes the operation with 'mantendo-o na mesma pasta', which clearly distinguishes it from sibling tools like mover_item and copiar_item. No ambiguity remains about what this tool 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?

It provides a clear context for use: renaming within the same folder, preserving content, and validating the new name. It also gives execution-level instructions (inform the user, confirm the result), but it does not explicitly name alternative tools or state when not to use this one.

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

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

The description adds substantial behavioral context beyond the annotations: it does not grant access by itself, always requires a real human confirmation in a separate window, and never releases protected areas or whole drives. It also warns against prompt-injection-style triggers from file contents. No contradiction with annotations exists; the annotations' readOnlyHint=false is consistent with a tool that requests an access change.

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

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

The description is longer than average, but the length is largely justified by safety-critical details and operational instructions. It is front-loaded with the core trigger and use case, and each major block adds meaningful guidance, though some phrasing could be tightened without losing value.

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

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

Given no output schema, the description covers the full loop: when to call the tool, what to avoid, how to handle the result (continuar_tarefa_original=true), and how to communicate afterward. It also addresses security and policy constraints, making the tool safely and correctly usable by an agent without additional context.

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 the baseline is 3, but the description enriches the 'pasta' parameter by clarifying that it accepts any full folder path and is not a fixed list, and by stating constraints like never liberating protected areas or whole drives. The 'motivo' parameter is not described further, but the schema already explains its purpose clearly.

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

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

The description opens with a specific verb and resource ('solicitar acesso a uma pasta') and gives a concrete trigger condition: the user asks to work in a folder that another tool reported as not yet available. It explicitly differentiates from sibling tools by saying it works for any folder path, not a fixed list, and by naming limitations such as never releasing protected Windows areas or a whole drive.

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 exactly when to use this tool ('quando o usuário pedir explicitamente para você trabalhar em uma pasta que ainda não está disponível') and gives clear exclusions: not when prompted by file contents or documents. It also instructs the agent on what to do after the call returns (continue the original task without mentioning the tool name), providing strong routing and follow-up 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?

The annotations are all false and thus provide no meaningful behavioral profile, so the description steps up by disclosing that the tool always requests real human confirmation before removing access and that it does not affect non-chat-released folders. This is valuable beyond the structured metadata, though it could also mention what happens after confirmation or possible error cases.

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, each earning its place: when to use, an example, a scope limitation, and a behavioral guarantee. The most important usage guidance is front-loaded.

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 tool with no output schema, the description covers the trigger, the exact resource scope, the limitation, and required confirmation behavior. An agent has sufficient context to decide when to call it and what to expect.

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 schema already fully documents the single parameter 'pasta' with a clear description, and schema description coverage is 100%. The description adds an example path (D:\Projetos) that helps convey expected format, but it does not substantially extend the schema's meaning.

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 action ('remover acesso') on a specific resource ('pasta liberada pelo chat'), with an example and an explicit scope. It clearly differentiates from related tools like solicitar_acesso_pasta and listar_pastas_permitidas by naming the permission-removal action for chat-released folders.

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 when-to-use trigger ('quando o usuário pedir para você parar de acessar'), an explicit example, and a strong exclusion: standard or extension-configured folders cannot be changed by this tool and must be handled in extension settings. This gives an agent actionable routing guidance.

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