Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Change one of my events (name, time, place, description, capacity)

connections_event_update
DestructiveIdempotent

Use this when the member asks to change, edit, rename, move or reschedule one of their own hosted events ('move my meetup to Friday at 7', 'rename the event', 'change the location', 'cap it at 50 people'). Changes only the fields you pass; every other setting, ticket tier and question stays as it is. A published event's public page shows the change at once, and this tool does not message the guests, so tell the member to let them know about a new time or place. To publish, cancel or delete, use those tools instead. Call it with dry_run:true first to show the member exactly what would change. Only the event's owner can edit it here.

Input Schema

NameRequiredDescriptionDefault
titleNoThe new name.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
dry_runNotrue = say exactly what would change, and change nothing. Do this first.
ends_atNoNew end time, in the same form.
projectNoWorkspace to run this call in (id or name).
capacityNoThe most guests who can register. null removes the limit.
event_idYesThe id of the member's own event (find it with connections_events_list).
locationNoNew public location label: a city, venue name, or 'virtual'. Empty clears it.
timezoneNoThe event's time zone as an IANA name, e.g. 'America/Chicago'. Its page shows times in this zone.
starts_atNoNew start time: an ISO date-time, e.g. 2027-01-15T18:00 with timezone, or with its offset.
descriptionNoNew description for the public page. It replaces the old one whole.
guests_see_who_cameNoAfter the event, checked-in guests see who else came. false turns it off.
guest_list_visibilityNoWho sees the guest list before the event: public (names), count_only (just the number), hidden.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / ends_at / description
      Previous value: -"New end time: an ISO date/time string, or unix seconds."New value: +"New end time, in the same form."
    • 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})?)?$"
    • changedInput schema / properties / starts_at / description
      Previous value: -"New start time: an ISO date/time string, or unix seconds."New value: +"New start time: an ISO date-time, e.g. 2027-01-15T18:00 with timezone, or with its offset."
    • 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})?)?$"
  2. Changed2 schema fields changed
    • addedInput schema / properties / capacity / nullable
      Added value: +true
    • changedInput schema / properties / capacity / type
      Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"
  3. Changed1 schema field changed
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "The event's time zone as an IANA name, e.g. 'America/Chicago'. Its page shows times in this zone.",
+  "type": "string"
+}
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare a destructive, idempotent, open-world write, and the description adds behavior well beyond that: patch semantics ('Changes only the fields you pass; every other setting, ticket tier and question stays as it is'), immediate public-page propagation, and the crucial fact that guests are NOT messaged — with an instruction to tell the member. That last point is exactly the kind of side-effect disclosure annotations cannot carry.

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 trigger condition and examples, then effects, then alternatives, then dry_run, then the ownership caveat — a logical escalation with little waste. Slightly long, and the trailing owner sentence could have been folded into the opening line.

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 13-parameter mutation with no output schema, it covers the high-risk unknowns: partial update, guest notification gap, public visibility, ownership, and the dry_run safe path. It does not address boundary cases such as lowering capacity below current registrations or the effect of a reschedule on already-published invitations.

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 explains every parameter including dry_run, event_id, capacity null semantics and description replacement. The description reinforces a couple of these (capacity, description, partial update) but contributes no meaning the schema lacks, which is the baseline for full coverage.

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 (change/edit) plus resource (one of the member's own hosted events) and enumerates the affected fields (name, time, place, description, capacity). It also explicitly separates itself from the publish/cancel/delete siblings, so an agent can route correctly without opening another 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?

Gives concrete trigger phrases ('move my meetup to Friday at 7', 'cap it at 50 people'), names the alternatives for other operations ('To publish, cancel or delete, use those tools instead'), and prescribes a call order: dry_run:true first, then the real change. It even states the ownership precondition.

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