Skip to main content
Glama

folders

Destructive

Manage Outlook mail folders by listing the folder tree, creating folders, moving emails, viewing counts, and deleting folders—addressed by name, path, or ID.

Instructions

Manage mail folders (tool-level destructiveHint=true because delete permanently removes a folder; list and stats are read-only sub-actions despite the annotation). Folders can be addressed by name, by a slash-separated PATH for nested folders (e.g. Triage/Delete, Inbox/Clients/Acme, case-insensitive), or by explicit ID; list output includes each folder's full path and [id: …]. A bare name resolves a unique top-level folder first, then searches nested folders (ambiguous names return the candidates — disambiguate with a path or ID). action=list (default) returns the folder tree (toggle includeItemCounts for unread/total, includeChildren for hierarchy). action=create makes a new folder under the root, or under parentFolder (name/path) / parentFolderId, and returns its id. action=move relocates emails (emailIds) into targetFolder (name/path) or targetFolderId. action=stats returns counts (totalItemCount/unreadItemCount) for folder (name/path) or folderId, suitable for pagination planning. action=delete removes a folder (by folderName/path or folderId) and its contents — on Outlook.com the folder is moved to Deleted Items (recoverable until you empty it); M365/Exchange accounts may hard-delete per retention policy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of the folder to create (action=create, required)
actionNoAction to perform (default: list)
folderNoFolder name or path (inbox, sent, "Triage/Delete", etc.). Default: inbox (action=stats)
emailIdsNoComma-separated list of email IDs to move (action=move, required)
folderIdNoFolder ID (action=stats/delete)
folderNameNoFolder name or path to delete — resolved to ID (action=delete). Cannot delete protected folders (Inbox, Drafts, Sent, etc.)
parentFolderNoParent folder name or path (e.g. "Clients/Acme"); default is root (action=create)
sourceFolderNoSource folder name, default is inbox (action=move)
targetFolderNoDestination folder name or path, e.g. "Triage/Delete" (action=move; or use targetFolderId)
parentFolderIdNoParent folder ID — alternative to parentFolder for unambiguous targeting (action=create)
targetFolderIdNoDestination folder ID — alternative to targetFolder for unambiguous/nested targeting (action=move)
includeChildrenNoInclude child folders in hierarchy (action=list)
outputVerbosityNoOutput detail level (action=stats, default: standard)
includeItemCountsNoInclude counts of total and unread items (action=list)
Behavior5/5

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

The description richly discloses behavioral details beyond the annotations: destructive delete semantics, read-only sub-actions, name/path/ID resolution, ambiguous-name fallback, and provider-specific differences (Outlook.com vs M365/Exchange). It clarifies and extends the destructiveHint annotation without contradicting it.

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

Conciseness4/5

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

The description is a single dense paragraph that packs in a lot of necessary information. It's not a model of conciseness, but every sentence adds operational value given the tool's complexity. A bulleted structure might improve scannability, but the length is justified.

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

Completeness5/5

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

For a 14-parameter tool with no output schema, the description is remarkably complete. It covers all actions, addressing schemes, return values (e.g., list output includes path and [id: ...]), constraints (cannot delete protected folders), and provider behavior differences. It leaves no major operational gaps.

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

Parameters5/5

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

Although the schema already covers all parameters, the description adds crucial semantics: how name/path/ID addressing works, case-insensitivity, path examples, and which parameters pair with which actions (e.g., parentFolder vs parentFolderId). This is far more valuable than the schema's isolated field descriptions.

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

Purpose5/5

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

The description clearly identifies the tool as managing mail folders and enumerates five specific actions (list, create, move, stats, delete), each with a distinct purpose. It differentiates from sibling email tools by focusing entirely on folder operations and provides concrete examples of addressing.

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

Usage Guidelines4/5

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

Each action has explicit context: when to use it, required parameters, and defaults (e.g., 'action=list (default) returns the folder tree'). The description notes stats is 'suitable for pagination planning' and explains move/delete prerequisites. It doesn't explicitly name alternatives among sibling tools, but the scope is clear enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/littlebearapps/outlook-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server