Skip to main content
Glama
epinethrone

icloud-mcp

by epinethrone
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mail_create_folder

Idempotent

Create a new empty iCloud Mail folder to file messages when no suitable folder exists. Use the exact, case-sensitive name; existing folders are not duplicated.

Instructions

Create a new, empty mail folder in the owner's iCloud mailbox.

Use when: the owner wants a place to file mail and mail_list_folders shows no suitable folder. Not for renaming (use mail_update_folder), for filing messages (create the folder, then use mail_move_messages or mail_run_bulk_action), or for removing one (use mail_delete_folder). Parameters: name is used exactly as given and is case-sensitive; 'Parent/Child' creates a subfolder where the server supports nesting. Pass the plain name, not an alias such as Sent. Behavior: creates nothing when a folder with that exact name already exists (the call succeeds with created=false, so repeating it is safe). Moves no mail. The folder appears on the owner's devices after sync. Returns: {created, name}; created=false with a note when it already existed. A name the server rejects raises an error naming it; check it against mail_list_folders.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the new folder.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mail_create_folderDictOutput",
-  "type": "object"
-}New value: +null
  2. Changed2 schema fields changedv0.7.0
    • removedInput schema / properties / name / title
      Removed value: -"Name"
    • removedInput schema / title
      Removed value: -"mail_create_folderArguments"
  3. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, but the description goes further: it explains that a duplicate name yields created=false with a note, that repeating the call is safe, that no mail is moved, and that the folder appears after device sync. This is rich behavioral context beyond the structured hints.

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?

Front-loaded with the action, then blocked into Use when / Parameters / Behavior / Returns. Every sentence carries distinct information; there is no repetition of the title or schema.

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?

With one parameter and no output schema, the description fully covers the gaps: return shape ({created, name}), the duplicate-name outcome, error behavior, and sync timing. An agent has everything needed to call it correctly and interpret the result.

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?

Schema coverage is 100%, but the description adds meaning the schema does not: the name is case-sensitive, 'Parent/Child' creates a subfolder where nesting is supported, and an alias like 'Sent' must not be passed. It also warns that a rejected name raises an error and points to mail_list_folders for checking.

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?

States a specific verb and resource ('Create a new, empty mail folder in the owner's iCloud mailbox') and scopes it precisely as empty and owner-owned. An agent can distinguish it from mail_update_folder, mail_delete_folder, and mail_move_messages without reading any schema.

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?

Explicit when-to-use ('owner wants a place to file mail and mail_list_folders shows no suitable folder') plus explicit when-not with named alternatives for renaming, filing, and deletion. Nothing is left to inference.

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

Deploy Server

Other Tools