Skip to main content
Glama
Sign In
icloud-mcp

icloud-mcp

by adamzaidi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

mark_older_than_read

Mark unread emails older than a specified number of days as read to bulk triage a cluttered inbox. Supports dry-run and mailbox selection.

Instructions

Mark all unread emails older than N days as read. Useful for bulk triage of a cluttered inbox.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "days": "<days>"
    },
    "name": "mark_older_than_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysYesMark emails older than this many days as read
dryRunNoIf true, report exactly what would change and do not modify anything
mailboxNoMailbox (default INBOX)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.8.0
    • addedInput schema / properties / dryRun
      Added value: +{
+  "description": "If true, report exactly what would change and do not modify anything",
+  "type": "boolean"
+}
  2. First observedv2.5.1

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It identifies a bulk mutation but does not disclose permissions, reversibility, side effects, or even mention the dryRun safety behavior described in the schema.

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?

Two short sentences with no wasted words. The purpose is front-loaded before the usage suggestion, making it easy to scan.

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

Completeness3/5

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

The description is adequate for a moderate three-parameter tool whose schema is fully documented and has no output schema. However, for a bulk mutation with no annotations, it should say more about safety and dry-run behavior to be fully complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline score is 3. The description does not add parameter-level meaning beyond what the schema already provides for days, dryRun, and mailbox.

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

Purpose4/5

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

The description states a specific verb, resource, and scope: mark unread emails older than N days as read. It clearly defines the operation, though it does not explicitly name or compare against sibling tools such as bulk_mark_read or mark_as_read.

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

Usage Guidelines3/5

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

It provides a usage context ('useful for bulk triage of a cluttered inbox'), which implies when to use it. However, it gives no explicit exclusions, prerequisites, or alternative tools for marking messages read.

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