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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It does so by stating that the tool returns item counts and full folder paths, and that it includes nested folders. This gives the agent a clear picture of the output and scope. It does not mention permissions, rate limits, or side effects, but as a read-only list operation, those are less critical. The description goes beyond a bare 'List folders' by specifying output characteristics, which is valuable.

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

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

The description is two sentences with zero filler. The first sentence front-loads the core function and key output details (nested folders, item counts, full paths). The second sentence adds a useful contrast with Gmail that aids selection. Every word earns its place, and the structure is 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?

For a list tool with only two parameters, full schema coverage, and no output schema, the description is nearly complete. It explains what is returned (item counts, full paths, nested folders) and the mailbox context. It does not mention pagination or error behavior, but for a folder listing that is likely not critical. The contrast with Gmail covers the sibling-selection need. A minor gap is the absence of an explicit read-only note, but that is implied by 'List'.

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%: both mailbox and includeHidden have descriptive text. The tool description does not add any extra parameter-specific meaning beyond what the schema already provides. It mentions mailbox is Outlook/Microsoft 365, which the schema also states. Per the rubric, with high schema coverage the baseline is 3, and the description does not elevate 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 states a specific action (list every mail folder), a resource (one mailbox), and adds detail (nested folders, item counts, full paths). It distinguishes itself from Gmail's label model by explicitly contrasting with Gmail, which helps an agent pick this over list_gmail_labels. The verb 'List' and resource 'mail folders' are unambiguous.

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

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

The description gives clear context: it's for Outlook/Microsoft 365 mailboxes, and it contrasts with Gmail's folder model, implying it should be used when working with Outlook rather than Gmail. It does not explicitly name alternatives like list_gmail_labels or list_messages, but the 'Unlike Gmail' note provides a strong usage signal. It lacks an explicit 'when not to use' clause, but the context is sufficient for an agent to infer.

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