Aisle

Update Wedding Event

update_my_event

DestructiveIdempotent

Updates supplied name, type, schedule, venue, dress code or description fields for an identified event in the selected wedding. Omitted fields and existing invitations and responses remain unchanged. Null clears the end time, venue, address, dress code or description. Results identify saved changes with their previous values. Requires sign-in and an Aisle membership.

Input Schema

Name	Required	Description
`date`	No	Event start. A time with no offset, such as 2027-06-12T18:00, is the wedding's local time; one ending in Z or an offset is that exact instant.
`name`	No	Event name
`type`	No	Event type
`all_day`	No	True for an all-day item with a day and no time, such as a travel day or a free day. Send date as the day (2027-06-12) and end_time as its last day for one that runs several days; a time sent with it is dropped.
`end_time`	No	Event end time, read the same way as date., or null to clear it
`event_id`	Yes	Identifier of the event to update in the selected wedding.
`dress_code`	No	Dress code (e.g. Black Tie, Smart Casual), or null to clear it
`venue_name`	No	Venue name for this event, or null to clear it
`wedding_id`	No	Identifier of a wedding the signed-in account can manage. Required when the account has multiple weddings.
`description`	No	Event description, or null to clear it
`venue_address`	No	Venue address, or null to clear it

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / all_day

Added value: +{
+  "description": "True for an all-day item with a day and no time, such as a travel day or a free day. Send date as the day (2027-06-12) and end_time as its last day for one that runs several days; a time sent with it is dropped.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 12, 2026

changedInput schema / properties / date / description

Previous value: -"Event date/time (ISO format)"New value: +"Event start. A time with no offset, such as 2027-06-12T18:00, is the wedding's local time; one ending in Z or an offset is that exact instant."

changedInput schema / properties / end_time / description

Previous value: -"Event end time (ISO format), or null to clear it"New value: +"Event end time, read the same way as date., or null to clear it"

Changed2 schema fields changedOct 12, 2026

addedInput schema / properties / event_id / format
```
Added value: +"uuid"
```

addedInput schema / properties / event_id / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changed15 schema fields changedOct 11, 2026

addedInput schema / properties / description / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / description / description

Previous value: -"Event description"New value: +"Event description, or null to clear it"

removedInput schema / properties / description / type
```
Removed value: -"string"
```

addedInput schema / properties / dress_code / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / dress_code / description

Previous value: -"Dress code (e.g. Black Tie, Smart Casual)"New value: +"Dress code (e.g. Black Tie, Smart Casual), or null to clear it"

removedInput schema / properties / dress_code / type
```
Removed value: -"string"
```

addedInput schema / properties / end_time / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / end_time / description

Previous value: -"Event end time (ISO format)"New value: +"Event end time (ISO format), or null to clear it"

removedInput schema / properties / end_time / type
```
Removed value: -"string"
```

addedInput schema / properties / venue_address / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / venue_address / description

Previous value: -"Venue address"New value: +"Venue address, or null to clear it"

removedInput schema / properties / venue_address / type
```
Removed value: -"string"
```

addedInput schema / properties / venue_name / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / venue_name / description

Previous value: -"Venue name for this event"New value: +"Venue name for this event, or null to clear it"

removedInput schema / properties / venue_name / type
```
Removed value: -"string"
```

First observedOct 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: omitted fields and existing invitations/responses are preserved, null explicitly clears specific fields, results echo previous values, and it requires sign-in plus an Aisle membership. The destructiveHint is substantiated by the concrete null-clearing rules rather than contradicted.

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 core action, then layered with preservation, null, return, and auth details, all of which earn their place. The field enumeration is slightly repetitive across sentences but not wasteful.

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 an 11-parameter mutation with no output schema, it covers the essentials: partial-update behavior, null semantics for clearing, what the response contains, and the auth/membership prerequisite. Nothing an agent needs to call it correctly is missing.

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 every parameter including the null-clearing semantics. The description's field lists largely restate the schema rather than adding syntax or format detail, so the baseline 3 applies.

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 (updates) and resource (event fields in the selected wedding) with the partial-update scope made explicit. An agent can distinguish this from add_my_event, remove_my_event, and get_my_event without opening 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 Guidelines4/5

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

The partial-update semantics ('Omitted fields ... remain unchanged') and null-clearing rules give clear context for how and when to call it. However, it never names alternatives (e.g. add_my_event for new events) or states exclusions, leaving routing to inference from the sibling names.

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

All Aisle tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?