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

With no annotations, the description carries the burden of behavioral disclosure. It states the tool returns events, implying a read operation, but does not specify nuances such as whether it includes all-day events, timezone handling, or whether it covers events that started before today but end today. It is adequate but minimally transparent.

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, concise sentence that immediately conveys the tool's function. It is front-loaded and contains no extraneous information, making it highly efficient.

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

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

The tool has low complexity (0 params, no output schema) and no annotations. The description provides the core behavior but omits important contextual details such as the scope of events (all calendars vs. default), date-range boundaries, and how results are structured. An agent might not know how to interpret the output without additional information.

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 schema coverage is trivially 100%. According to the rubric, a 0-parameter tool gets a baseline score of 4. The description adds no parameter-related details because there are none to explain, which 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 verb 'returns' and the resource 'today's events in the Outlook calendar', making the tool's purpose unambiguous. It naturally distinguishes itself from sibling tools like outlook_agenda_semana (week) and outlook_detalhes_evento (event details) by specifying 'today'.

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 no explicit guidance on when to use this tool versus alternatives. While the name and description imply it is for today's agenda, there is no mention of when not to use it or that outlook_agenda_semana should be used for weekly views. The guidance is entirely absent.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Retorna' discloses a read-only operation, but nothing is said about return structure, event fields, ordering, timezone handling, or how edge cases (e.g., dias=0, canceled events) behave. For an unannotated tool this is a meaningful gap.

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

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

A single front-loaded sentence states the verb, resource, and scope with no waste. It is appropriately sized for a simple read tool, though it could have included a second sentence on behavior or return format without becoming bloated.

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

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

With no output schema and no annotations, the description should disclose what the returned events look like, but it is silent on return format. It also fails to clarify the selection boundary versus outlook_agenda_hoje. The calling contract (params) is covered, but an agent still lacks key operational details.

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. The description only echoes 'N dias' which maps to the dias parameter and adds nothing beyond the schema about the usuario parameter or value constraints. The schema already carries the meaning, so no penalty, but also no added value.

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 ('Retorna'/'Returns') with a clear resource ('eventos no calendário') and a scoping qualifier ('próximos N dias'). It is distinguishable from the sibling outlook_agenda_hoje through the 'N dias' scope and from inbox/detail tools by the resource. However, it doesn't explicitly name any sibling to contrast with.

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

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

Usage is implied: 'próximos N dias' suggests this is for multi-day lookahead windows, implicitly distinct from outlook_agenda_hoje (today only) and outlook_detalhes_evento (singular event). But there is no explicit when-to-use, when-not-to-use, or mention of alternative tools, leaving the agent to infer the boundary.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does explicitly state the destructive/cancelling nature of the operation, but it does not mention irreversibility, permission requirements, or the recurrence consequence of apenas_este=false, which is only revealed in the 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 first sentence is concise and front-loaded with the core action. The second sentence, 'Chaves alinhadas ao backend FastAPI,' is vague and does not help an agent select or invoke the tool, so not 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?

The schema handles parameter documentation well, including recurrence behavior, and the core operation is clear. However, without annotations or an output schema, the description leaves gaps around expected results, error cases, and the destructive consequences of deleting an event.

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

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

Schema coverage is 100%, so all three parameters are already documented. The description adds no extra parameter semantics; the note about FastAPI-aligned keys is a naming convention rather than meaningful parameter guidance.

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

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

The description opens with a specific action ('Cancela/exclui') and a clear resource ('um evento do calendário'), making the deletion/cancellation purpose unmistakable. This clearly differentiates it from sibling tools like outlook_criar_evento, outlook_editar_evento, and outlook_detalhes_evento.

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 states what the tool does but gives no guidance on when to use it instead of alternatives. There are no exclusions, prerequisites, or explicit comparisons to siblings such as outlook_editar_evento or outlook_criar_evento.

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?

Sem anotações, a descrição carrega todo o peso da transparência comportamental, mas apenas afirma a criação de um evento. Não menciona efeitos colaterais, requisitos de autenticação, idempotência ou formato de retorno, deixando lacunas significativas para uma operação de escrita.

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 é uma frase única, concisa e direta, sem palavras desnecessárias. A estrutura é simples e o propósito é front-loaded, embora seja extremamente enxuta, o que é apropriado para este nível de simplicidade.

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?

Com 7 parâmetros, nenhum esquema de saída e nenhuma anotação, a descrição é insuficiente para um agente usar corretamente. Não explica o que acontece em caso de sucesso, possíveis erros, ou como os parâmetros obrigatórios se relacionam, exigindo inferência excessiva do esquema.

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 descrição não adiciona nenhuma informação sobre parâmetros. A cobertura do esquema é de 57% (4 de 7 parâmetros com descrição), mas a descrição não compensa os parâmetros sem documentação, como 'local' e 'descricao', nem fornece contexto adicional além do que o esquema já oferece.

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 'Cria um novo evento no calendário do Outlook' apresenta um verbo específico (criar) e um recurso claro (evento no calendário do Outlook), diferenciando-se implicitamente de ferramentas irmãs como editar, cancelar ou listar. No entanto, não menciona explicitamente alternativas, o que impede uma pontuação máxima.

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?

Não há orientação sobre quando usar esta ferramenta em vez de outras, como outlook_editar_evento ou outlook_cancelar_evento. A descrição é uma frase única sem contexto de uso ou exclusões, deixando o agente sem critérios de seleção.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool reads the full body of an event, which implies a read-only operation, but it does not mention whether it requires exact title matching, how it handles multiple events with the same title, or whether it returns the body in a specific format. The read-only nature is implied but not explicit.

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, focused sentence that front-loads the main purpose and gives concrete examples of use. It is concise and efficient, though it could be slightly more structured with explicit usage guidance.

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

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

For a simple read tool with two parameters and no output schema, the description is mostly adequate. However, it lacks guidance on edge cases like duplicate titles, partial matches, or what happens if the event is not found. Given the sibling tools include editing and creating events, a bit more context on how this read tool fits in would improve completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context that the parameters are used to locate the event, but it does not add details like whether 'titulo' supports partial matching or whether 'data' is required for disambiguation. Baseline 3 is appropriate since the schema covers the basics.

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 ('Lê') and resource ('corpo completo de um evento'), and gives concrete use cases (PNR de voo, link Teams, notas). It is clear what the tool does, though it does not explicitly differentiate from siblings like outlook_editar_evento or outlook_criar_evento.

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 it: when you need the full body of an event, especially for details like PNR or Teams link. However, it does not explicitly state when not to use it or name alternatives, such as outlook_agenda_hoje for a summary or outlook_editar_evento for modifying the event.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'consulta' (queries), which implies a read operation, but it does not describe permissions, whether data is read-only, how results are returned, or any limitations. This is a significant gap for a calendar-access 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 a single, efficient sentence with no filler or repetition. It front-loads the main purpose and gives a clarifying example, though it could be slightly more structured by mentioning the time window.

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 no output schema and no annotations, the description is incomplete. It does not explain what the returned data looks like, how 'dias' affects the query, or how this relates to other calendar tools. An agent cannot fully determine expected behavior or output from the description 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?

Schema description coverage is 0%, so the description must compensate. It adds some meaning for 'nome_usuario' by giving examples (name or email), but it says nothing about 'dias', leaving the integer's role, range, and default behavior unexplained.

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

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

The description clearly states the action ('consulta a agenda') and the target resource (a managed user's calendar), and it gives an example of the user identifier. However, it does not distinguish this tool from siblings like outlook_freebusy, outlook_agenda_hoje, or outlook_agenda_semana, leaving some ambiguity about whether this returns events or availability.

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

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

No guidance is provided about when to use this tool instead of alternatives. The phrase 'de um usuário gerenciado' implies it is for another person's calendar, but there is no explicit mention of when this is preferable to outlook_freebusy or the agenda tools, nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool edits an event, but does not disclose permissions required, whether updates are partial or full replacement, what happens if the event is not found, or whether changes are irreversible. The phrase 'Chaves alinhadas ao backend FastAPI' is cryptic and does not clarify behavior.

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

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

The description is short and front-loaded with the core purpose. The second sentence 'Chaves alinhadas ao backend FastAPI' is somewhat vague and could be considered noise, but it is brief and does not detract significantly. Overall, every sentence earns its place, though the backend-key remark is of marginal value.

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

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

For an update tool with 7 parameters, no output schema, and no annotations, the description is too thin. It should explain the lookup mechanism (titulo_parcial/data_busca), state that only provided fields will be updated, and clarify expected behavior when no new field is supplied or when the event is missing. These details are missing, leaving the agent to infer the workflow solely from the schema.

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

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

Schema description coverage is 71%, so the schema already documents most parameters. The description adds grouping of fields (title, date, time, description) which helps map intent to parameters, but does not provide deeper semantics beyond what the schema already says – e.g., it doesn't clarify that nova_data/nova_hora_* are meant as replacements or that titulo_parcial is the search key. This is acceptable but not compensatory for the 29% undocumented parameters.

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

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

The description states a specific verb and resource: 'Edita um evento existente no calendário' (edits an existing calendar event) and lists the editable fields (título, data, hora ou descrição). This clearly distinguishes it from siblings like outlook_criar_evento and outlook_cancelar_evento by specifying 'existing event'.

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 tool's use is implied by 'edita um evento existente' – an agent can infer it should be used when modifying an existing event rather than creating or canceling one. However, there is no explicit statement of when to use it versus alternatives, nor any exclusions such as 'use outlook_criar_evento if the event does not exist yet'.

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 are absent, so the description must disclose behavioral traits. It only states that it sends an email, but it does not mention that it is a mutating action, may require authentication permissions, could have rate limits, or what the return value is. For a send action with no annotations, this is a significant gap.

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 one short sentence that is front-loaded with the verb and resource. It is concise with no waste. However, it could afford to be slightly longer to include usage guidance, but it is not bloat.

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 lack of annotations and output schema, the description is incomplete for a mutating tool. It does not mention authentication requirements, potential errors (e.g., invalid recipients), success response, or whether a confirmation is returned. The schema is rich enough for parameters, but the description lacks behavioral 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 description coverage is 75% (para, corpo, cc are described, assunto is not). The description adds little beyond the schema; it confirms the body can be text or HTML, which is also in the schema. The main gap is that 'assunto' has no description, and the tool description doesn't compensate. 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?

The description clearly states the verb (Envia) and resource (email via Outlook da conta autenticada), which is specific enough to differentiate from sibling tools like outlook_inbox (reading) and outlook_criar_evento (creating events). However, it does not mention the subject or recipients explicitly, though these are in the schema. It does not explicitly differentiate from other write tools, but the purpose is clear.

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

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

The description implies this tool is used to send emails, but it does not provide explicit guidance on when to use it versus alternatives, such as when to use outlook_criar_evento for calendar invitations instead. Since the siblings are mostly for reading, the context is clear enough for basic selection, but no exclusions or conditions are given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what it returns (e.g., list of busy/free slots, first available slot), or any limitations such as needing email format validation or timezone handling. The description only says 'consulta' (query), implying read, but does not elaborate on side effects or output structure.

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 sentence with high information density, front-loading the core purpose (free/busy check) and the key outcome (finding common time). No superfluous words, so it is appropriately concise.

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

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

The tool has 3 required parameters and no output schema, so the description must compensate. It explains the goal (common time) but does not specify return format, pagination, or failure behavior. Given that annotations are absent, an agent would not know what to expect from the tool call, making it incomplete for a tool with this complexity.

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

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

Schema description coverage is 100%, so the schema already documents the parameters (emails, data_inicio, data_fim) with formats like ISO 8601. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't clarify that emails must be valid or that the time range is inclusive). It reinforces the purpose but doesn't add value, so 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?

The description clearly states the tool checks availability/free-busy for multiple participants to find a common time. The verb 'consulta disponibilidade' is specific and the resource is free/busy availability, distinguishing it from siblings like 'outlook_inbox' or 'outlook_criar_evento'. However, it does not explicitly differentiate from sibling 'outlook_disponibilidade' which may be a closely related tool.

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

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

The description implies usage for finding common available time across participants, which is useful context. But it does not provide when-to-use vs. alternatives, nor exclusions. It mentions 'para encontrar horário comum' (to find a common hour), which gives some guidance, but it lacks explicit alternatives or conditions that would help an agent choose this over other scheduling 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?

With no annotations, the description carries the full burden. It discloses what fields are returned (sender, subject, date, preview), which is useful. However, it omits details like ordering, whether only unread emails are listed, or any side effects. It is not misleading, but minimal for a read operation.

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

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

The description is a single, focused sentence with no filler. It front-loads the core purpose and includes the return fields efficiently. Perfectly concise for a simple tool.

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

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

For a simple list tool with one parameter and no output schema, the description covers the core functionality and return structure. It does not mention ordering or pagination, but these are not critical for basic use. The main gap is the lack of explicit sibling differentiation, but that is covered under usage guidelines.

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% for the single parameter 'limite', which already defines its meaning and default. The tool description adds no additional semantics or usage examples beyond the schema, 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 clearly states the tool lists emails from the authenticated account's Outlook inbox, specifying the verb 'Lista' and the resource. It also mentions the return fields (sender, subject, date, preview), which helps distinguish it from sibling tools like sending emails or calendar operations. The implicit distinction from 'outlook_inbox_compartilhado' is present via 'da conta autenticada'.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention the sibling 'outlook_inbox_compartilhado' for shared inboxes or any exclusions. There is no hint of when not to use it, leaving the agent to infer from the name alone.

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

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

No annotations are provided, so the description carries the behavioral burden. It clearly indicates a read-style list operation, but it does not mention return format, pagination, access requirements, or any potential side effects.

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

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

A single compact sentence with no filler. The action and resource are front-loaded, making it immediately scannable for an agent.

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 list operation with no output schema, the description sufficiently states what is returned (emails) and for which mailbox. It does not detail output fields, but that is not a major gap here.

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 parameter already has a description. The tool description adds a concrete example address ('agenda@dominio.com'), which reinforces the expected format beyond the schema alone.

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

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

The description uses a specific verb ('Lista') and a specific resource ('emails de uma caixa compartilhada do Outlook'). It clearly separates this tool from the sibling outlook_inbox by emphasizing the shared mailbox scope, plus a concrete example address.

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

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

Usage context is implied: use this tool for shared Outlook mailboxes rather than a personal inbox. However, the description does not explicitly state when to prefer this over alternatives or mention exclusions.

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