Aisle

Update Accommodation

update_my_accommodation

DestructiveIdempotent

Updates supplied room details, pricing, payment requirements or deposit and balance schedules in the selected wedding. Omitted fields remain unchanged. Null clears the room type, description, stay dates, check-in and check-out times or check-in notes. Setting a price enables payment unless explicitly disabled; zero makes the room free. Results return the saved room details, identify saved changes with their previous values and describe whether payment is available. This tool does not initiate a charge. Requires sign-in and an Aisle membership.

Input Schema

Name	Required	Description
`status`	No	unavailable takes the room out of the block
`capacity`	No	How many it sleeps
`room_name`	No	The room name
`room_type`	No	e.g. "Double", "Suite", or null to clear it
`price_unit`	No	What the amount buys
`wedding_id`	No	Identifier of a wedding the signed-in account can manage. Required when the account has multiple weddings.
`description`	No	Room description, or null to clear it
`deposit_unit`	No	How the deposit is stated: "amount" for a flat sum, "percent" for a share of whatever the room comes to
`price_amount`	No	The rate, or null to clear it, or 0 to make it free
`check_in_date`	No	Check-in date (ISO format), or null to clear it
`check_in_time`	No	e.g. 3:00 PM, or null to clear it
`check_in_notes`	No	Check-in notes, or null to clear it
`check_out_date`	No	Check-out date (ISO format), or null to clear it
`check_out_time`	No	e.g. 11:00 AM, or null to clear it
`deposit_amount`	No	What guests pay up front, with the rest due by balance_due_date. Null clears the schedule so the room is paid whole; 0 takes this room off a schedule its property sets.
`accommodation_id`	Yes	Identifier of the room to update in the selected wedding.
`balance_due_date`	No	YYYY-MM-DD, the day payment is due. Beside a deposit it dates the rest; on a room with no deposit it dates the whole price. Without it the room still charges, but nothing chases it.
`deposit_due_date`	No	YYYY-MM-DD, the day the deposit is due. Without it the guest site says the deposit is due now. A date after balance_due_date is dropped.
`requires_payment`	No	Whether guests pay for this room

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / price_unit / enum

Previous value: -[
-  "room",
-  "night",
-  "party",
-  "head"
-]New value: +[
+  "room",
+  "night",
+  "party",
+  "head",
+  "open"
+]

Changed2 schema fields changedOct 12, 2026

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

addedInput schema / properties / accommodation_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)$"

Changed21 schema fields changedOct 11, 2026

addedInput schema / properties / check_in_date / anyOf

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

changedInput schema / properties / check_in_date / description

Previous value: -"Check-in date (ISO format)"New value: +"Check-in date (ISO format), or null to clear it"

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

addedInput schema / properties / check_in_notes / anyOf

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

changedInput schema / properties / check_in_notes / description

Previous value: -"Check-in notes"New value: +"Check-in notes, or null to clear it"

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

addedInput schema / properties / check_in_time / anyOf

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

changedInput schema / properties / check_in_time / description

Previous value: -"e.g. 3:00 PM"New value: +"e.g. 3:00 PM, or null to clear it"

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

addedInput schema / properties / check_out_date / anyOf

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

changedInput schema / properties / check_out_date / description

Previous value: -"Check-out date (ISO format)"New value: +"Check-out date (ISO format), or null to clear it"

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

addedInput schema / properties / check_out_time / anyOf

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

changedInput schema / properties / check_out_time / description

Previous value: -"e.g. 11:00 AM"New value: +"e.g. 11:00 AM, or null to clear it"

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

addedInput schema / properties / description / anyOf

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

changedInput schema / properties / description / description

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

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

addedInput schema / properties / room_type / anyOf

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

changedInput schema / properties / room_type / description

Previous value: -"e.g. \"Double\", \"Suite\""New value: +"e.g. \"Double\", \"Suite\", or null to clear it"

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

First observedOct 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations give destructive/idempotent/readOnly/openWorld hints, but the description adds genuine behavioral depth: partial-update semantics, which fields null clears, the price-enables-payment coupling with zero meaning free, the returned previous-values diff, and the sign-in plus membership requirement. This exceeds what the structured annotations convey.

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?

Four sentences, each carrying distinct information — update scope, null/omit semantics, payment coupling, and return/auth behavior — with the core operation front-loaded. No filler or restated title text.

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 19-parameter mutation tool with no output schema, the description covers what the tool writes, how null vs omission differ, the payment side effects, the returned result shape (saved details plus previous values), and the auth prerequisites. Nothing an agent needs to invoke it correctly is missing.

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, but the description adds cross-parameter meaning the schema does not state: setting price_amount implicitly enables payment unless disabled, and zero makes the room free. It nonetheless does not clarify the deposit/balance due-date interaction beyond what the schema already documents, so it stops short of a 5.

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 (room details, pricing, payment/deposit schedules) scoped to the selected wedding, which cleanly separates it from add_my_accommodation, get_my_accommodation and remove_my_accommodation. An agent can identify the operation without opening the 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?

Gives strong invocation guidance: omitted fields remain unchanged, null clears specific fields, and it explicitly disclaims initiating a charge ('This tool does not initiate a charge'). It does not, however, route the agent to alternatives such as get_my_accommodation for reads or add_my_accommodation for creation, so no explicit when-not guidance exists.

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?