Skip to main content
Glama
Sign In
icloud-mcp

icloud-mcp

by adamzaidi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

bulk_update_events

Update multiple iCloud calendar events in one call by providing each event ID and only the fields to change, optionally previewing changes with a dry run.

Instructions

Update multiple calendar events in one call. Each update object must include eventId and only the fields to change.

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": {
      "calendarId": "<calendarId>",
      "updates": "<updates>"
    },
    "name": "bulk_update_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
dryRunNoIf true, report exactly what would change and do not modify anything
updatesYesArray of update objects, each with eventId (required) plus any fields to change: summary, start, end, timezone, allDay, description, location, recurrence, status, reminder
calendarIdYesCalendar ID containing the events

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.8.0

TDQS

A3.6/5.0
Behavior3/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 does disclose meaningful semantics ('only the fields to change'), clarifying this is a partial/patch update, but it is silent on atomicity, what happens if one eventId fails mid-batch, permissions, and it never surfaces the dryRun behavior that the schema describes.

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 tightly scoped sentences with zero waste, and the core purpose is front-loaded ahead of the structural constraint. Nothing is padded or redundant.

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?

For a bulk mutation with no annotations and no output schema, the description covers what an agent needs to construct a correct call (eventId required, only changed fields). It drops the dryRun capability and any batch-failure semantics, leaving minor gaps.

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 schema already documents calendarId, dryRun, and the update fields. The description reinforces the eventId requirement and partial-update semantics, adding modest value, but introduces no format or syntax detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb ('Update') and resource ('multiple calendar events') with the batch scope made explicit via 'in one call,' which distinguishes it from the singular update_event sibling. It does not name update_event or the other bulk_* event siblings directly, so it stops short of full sibling differentiation.

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?

The phrase 'multiple ... in one call' implies the batch use case versus single-event updates, but the description never states when to prefer this over update_event, nor any exclusions or prerequisites. Usage is implied rather than spelled out.

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