Skip to main content
Glama

folders

Destructive

Manage Outlook mail folders: list hierarchy with item counts, create new folders, move emails to target folders, get statistics, and permanently delete folders.

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). action=list (default) returns the folder tree with id/displayName/parentFolderId (toggle includeItemCounts for unread/total, includeChildren for hierarchy). action=create makes a new folder under the inbox (or under folder/folderId/folderName) and returns its id. action=move relocates emails (emailIds array) into targetFolder. action=stats returns counts (totalItemCount/unreadItemCount) suitable for pagination planning — pair with outputVerbosity to limit noise. action=delete permanently removes a folder and its contents — there is no recycle-bin recovery.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoAction to perform (default: list)
includeItemCountsNoInclude counts of total and unread items (action=list)
includeChildrenNoInclude child folders in hierarchy (action=list)
nameNoName of the folder to create (action=create, required)
parentFolderNoParent folder name, default is root (action=create)
emailIdsNoComma-separated list of email IDs to move (action=move, required)
targetFolderNoFolder name to move emails to (action=move, required)
sourceFolderNoSource folder name, default is inbox (action=move)
folderNoFolder name (inbox, sent, drafts, etc.). Default: inbox (action=stats)
outputVerbosityNoOutput detail level (action=stats, default: standard)
folderIdNoFolder ID to delete (action=delete)
folderNameNoFolder name to delete — resolved to ID (action=delete). Cannot delete protected folders (Inbox, Drafts, Sent, etc.)
Behavior4/5

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

The description adds transparency beyond annotations by noting that delete is permanent and that list/stats are read-only despite destructiveHint. However, it does not disclose auth requirements or rate limits, which would further enhance transparency.

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 dense but well-organized, covering all actions in a single paragraph. It front-loads the critical annotation contradiction note. Breaking into bullet points would improve scannability, but it remains concise with no redundancy.

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?

Given 12 parameters, no output schema, and 5 actions, the description is exceptionally complete. It explains each action's behavior, key parameters, and expected returns (e.g., list returns tree with id/displayName/parentFolderId). No gaps are apparent.

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?

With 100% schema coverage, the description enriches parameter meanings by clarifying defaults (e.g., parentFolder for create defaults to root), return values (e.g., stats returns counts useful for pagination), and contextual usage (e.g., outputVerbosity pairing with stats).

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 with specific actions (list, create, move, stats, delete), each with a distinct purpose. It distinguishes itself from sibling tools like 'manage-category' or 'manage-rules' by focusing on folder operations.

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

Usage Guidelines5/5

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

The description provides explicit guidance for each action's usage, including default behaviors (e.g., action=list by default, create under inbox). It advises caution for delete (permanent, no recovery) and implies appropriate contexts through parameter explanations.

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