Aisle

Remove Accommodation

remove_my_accommodation

DestructiveIdempotent

Removes an identified room and its guest assignments from the selected wedding, subject to payment and checkout safeguards. Uncharged checkouts without a payment method require confirmed cancellation. Completed, refunded or processing payments and active checkouts with a card prevent removal. Payment history is retained. The place is retained unless remove_empty_place is set and the place has no other rooms or retained history; otherwise empty places require a separate explicit removal. Requires sign-in and an Aisle membership.

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": {
      "accommodation_id": "<accommodation_id>"
    },
    "name": "remove_my_accommodation"
  }
}

Input Schema

Name	Required	Description
`wedding_id`	No	Identifier of a wedding the signed-in account can manage. Required when the account has multiple weddings.
`accommodation_id`	Yes	Identifier of the room to remove from the selected wedding.
`remove_empty_place`	No	When true, also removes the room’s place if it has no other rooms or retained room history. Defaults to false, which keeps the place.

Schema Changelog

Changes observed during successful MCP inspections.

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)$"

Changed1 schema field changedOct 11, 2026

addedInput schema / properties / remove_empty_place

Added value: +{
+  "description": "When true, also removes the room’s place if it has no other rooms or retained room history. Defaults to false, which keeps the place.",
+  "type": "boolean"
+}

First observedOct 2, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare destructive/idempotent/openWorld and non-read-only; the description goes well beyond them by disclosing the payment and checkout safeguards that block deletion, that payment history is retained, the default place-retention behavior, and the auth/membership requirement. That is exactly the operational context a destructive tool needs.

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-loads the core action, then layers safeguards and the place-retention rule; every clause carries operational meaning. It is dense and slightly long, but no sentence is filler.

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 destructive mutation with annotations and no output schema, the description covers preconditions, blocking states, retention semantics, and auth. The only gap is what the caller receives on a blocked removal (error vs. partial effect), which is left implicit.

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 nonetheless adds interpretive value by explaining the retention rule that governs remove_empty_place (place kept unless the flag is set and no other rooms or retained history exist) and the payment-history interaction. It adds nuance rather than restating types.

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 ('Removes an identified room and its guest assignments') scoped to 'the selected wedding', which cleanly separates it from remove_my_place, remove_my_event, and remove_my_guest among the siblings. An agent can identify the target entity 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 clear when-not conditions (uncharged checkouts without a payment method require confirmed cancellation; completed/refunded/processing payments and active card-backed checkouts block removal) and points to the alternative path for empty places. It never names the sibling tool (remove_my_place) directly, so routing is described functionally rather than explicitly.

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

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

Need Help?