Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Change a calendar event

connections_calendar_update
DestructiveIdempotent

Use this when the member asks to move, reschedule, push back, shorten, extend or rename an event on their own Connections calendar ('move my 3pm 30 minutes later', 'rename the dentist event'). Changes ONE event by id (get the id from connections_calendar_list); only the fields you pass change. To move an event and keep its length, pass BOTH the new starts_at and ends_at. Only events the member added themselves can be changed; one another source put on the calendar (a hosted event, a connected Google Calendar) is changed where it came from. ALWAYS call with dry_run:true first, tell the member the change, and only run it for real once they confirm. It does NOT add an event (connections_calendar_add) or remove one (connections_calendar_delete).

Input Schema

NameRequiredDescriptionDefault
idYesThe event's id, from connections_calendar_list.
titleNoNew title. Omit to leave it.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
all_dayNotrue = whole-day event, false = timed. Omit to leave it.
dry_runNotrue previews the exact change without writing anything. Do this first.
ends_atNoNew end, same format. Omit to leave it.
projectNoWorkspace to run this call in (id or name).
timezoneNoOptional IANA time zone, e.g. 'America/Chicago', that plain wall-clock times (2027-01-15T10:00) are read in, daylight saving included. Leave it out to use the member's saved time zone.
starts_atNoNew start, an ISO 8601 date-time with the member's UTC offset (2027-01-15T10:30:00-06:00), or a plain wall-clock time read in timezone or the member's saved time zone. Omit to leave it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / starts_at / description
      Previous value: -"New start, an ISO 8601 date-time WITH the member's UTC offset, e.g. 2027-01-15T10:30:00-06:00. Omit to leave it."New value: +"New start, an ISO 8601 date-time with the member's UTC offset (2027-01-15T10:30:00-06:00), or a plain wall-clock time read in timezone or the member's saved time zone. Omit to leave it."
    • changedInput schema / properties / timezone / description
      Previous value: -"The member's IANA time zone, e.g. 'America/Chicago'. With it, times may be plain wall-clock times (2027-01-15T10:00) and the server applies the zone's offset, daylight saving included."New value: +"Optional IANA time zone, e.g. 'America/Chicago', that plain wall-clock times (2027-01-15T10:00) are read in, daylight saving included. Leave it out to use the member's saved time zone."
  2. Changed2 schema fields changed
    • addedInput schema / properties / ends_at / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d{1,9})?)?(Z|[+-]\\d{2}:?\\d{2})?$"
    • addedInput schema / properties / starts_at / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d{1,9})?)?(Z|[+-]\\d{2}:?\\d{2})?$"
  3. Changed1 schema field changed
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "The member's IANA time zone, e.g. 'America/Chicago'. With it, times may be plain wall-clock times (2027-01-15T10:00) and the server applies the zone's offset, daylight saving included.",
+  "type": "string"
+}
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: it discloses partial-update semantics ('only the fields you pass change'), the both-starts_at-and-ends_at requirement to preserve duration, an ownership constraint (only member-added events; externally sourced events must be changed at the source), and the dry_run preview-and-confirm protocol. These are non-obvious behaviors an agent would otherwise get wrong, and none of them are recoverable from destructiveHint/idempotentHint alone.

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?

Front-loaded with the triggering condition, then prerequisites, then the safety protocol, then exclusions — a sensible order with no filler sentences. It runs long as a single dense block, and the clause about events from another source is grammatically awkward ('one another source put on the calendar'), which slightly slows parsing.

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?

For a 9-parameter mutation tool with no output schema, the description covers the missing pieces: id provenance, partial-update behavior, coupled time parameters, ownership limits, and the dry-run/confirm loop. An agent can call this correctly without consulting anything else.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the omit-to-leave-unchanged convention across fields and the coupled relationship between starts_at and ends_at that the schema does not express. It does not, however, discuss timezone interaction with starts_at beyond what the schema already says.

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 ('move, reschedule, push back, shorten, extend or rename an event on their own Connections calendar') with concrete utterance examples, and explicitly scopes it to ONE event by id. It is immediately distinguishable from connections_calendar_add and connections_calendar_delete, both named in the text.

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?

Gives explicit when-to-use triggers in the member's own words, names the two sibling alternatives it is not (add, delete), states the prerequisite for obtaining the id (connections_calendar_list), and prescribes a mandatory dry_run-first workflow with member confirmation. Nothing about selection 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.

All Connections toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources