outlook_freebusy

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.