Skip to main content
Glama

folders

Destructive

List, create, move, or delete mail folders; retrieve folder statistics for pagination planning.

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.)
Behavior5/5

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

Beyond the annotations, the description explains that despite destructiveHint=true, list and stats are read-only. It also discloses that delete permanently removes folders with no recovery, and that certain protected folders cannot be deleted. This adds valuable behavioral context.

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

Conciseness5/5

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

The description is a dense, single paragraph that efficiently covers all five actions without redundant sentences. It front-loads the critical note about destructiveHint and read-only sub-actions, and each sentence earns its place.

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

Completeness4/5

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

Given the complex multi-action tool with 12 parameters and no output schema, the description is quite thorough. It covers inputs, outputs, and behaviors for each action. Minor omissions include lack of explicit error handling or return format for move/delete.

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, baseline is 3, but the description adds substantial meaning: it describes return values for list (folder tree with fields), create (returns id), stats (counts for pagination), and constraints on delete (protected folders). This goes beyond the schema 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 explicitly states it manages mail folders and enumerates five distinct sub-actions (list, create, move, stats, delete) with specific verbs and resources. It distinguishes itself from sibling tools by its focus on folder operations, making purpose immediately clear.

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?

The description provides clear context for when to use each sub-action, including the destructive nature of delete and the read-only nature of list and stats. It also mentions default behavior. However, it does not explicitly contrast with sibling tools like 'manage-rules' or 'access-shared-mailbox', which would strengthen guidance further.

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-assistant'

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