Skip to main content
Glama

Aisle

by wedding.aisle
OverviewDiscussionsAdmin

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.

Input Schema

NameRequiredDescriptionDefault
wedding_idNoIdentifier of a wedding the signed-in account can manage. Required when the account has multiple weddings.
accommodation_idYesIdentifier of the room to remove from the selected wedding.
remove_empty_placeNoWhen 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.

  1. Changed2 schema fields changed
    • 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)$"
  2. Changed1 schema field changed
    • 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"
+}
  3. First observed

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 toolsInspect
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