Lists Outlook mail folders with message counts, parent IDs, and child counts, showing top-level folders by default; use recursive mode to walk the full tree with each folder path.
List mail folders with message counts, parent_id, and child count.
Default is top-level only; pass recursive=True to walk the full tree, each folder with the
path that folder arguments accept.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| recursive | No |
Changes observed during successful MCP inspections.
v1.30.2Input schema / properties / cursor / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Input schema / properties / cursor / defaultRemoved value: -nullInput schema / properties / cursor / titleRemoved value: -"Cursor"Input schema / properties / cursor / typeAdded value: +"string"Input schema / properties / recursive / titleRemoved value: -"Recursive"Input schema / titleRemoved value: -"outlook_list_foldersArguments"v1.11.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring a safe read operation, the description adds useful behavior: default top-level scope, recursive full-tree behavior, and the path output relevant to folder arguments. It omits pagination/cursor behavior and does not clarify whether counts are total or unread, but it adds meaningful context beyond 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 two compact sentences, front-loaded with the core operation and return fields, followed by the key recursive behavior. There is no filler or repetition.
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-only listing tool with no output schema, it covers the main behavior, default scope, recursion, and important returned fields. It is not fully complete because cursor/pagination semantics are absent and the meaning of message counts is not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for undocumented parameters. It explains recursive well, including the default and effect, but cursor is completely unmentioned, leaving one of two parameters without any semantic 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 states a specific verb and resource, 'List mail folders', and names returned fields including message counts, parent_id, and child count. It is clearly a read/list operation, distinguishing it implicitly from folder mutation siblings, but it does not explicitly differentiate itself from tools like outlook_list_inbox or outlook_list_thread.
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 clear usage context for the recursive parameter: default is top-level only, and recursive=True walks the full tree. It does not name alternative tools or conditions for choosing this over list-inbox-style siblings, so it is clear but not fully comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.