Skip to main content
Glama

Cancel Booking

cancel_booking
Destructive

Cancel a booking owned by the authenticated account. Configure a valid TourMind user_key in a trusted local Skill or client integration that supplies the user_key tool argument. Do not ask users to paste user keys into chat. 普通 ToC 酒店查询可匿名,user_key 可选;下单、订单查询、取消和支付需要客户端安全配置的 user_key。 先查询订单,让用户明确确认具体订单及可能的取消费用后再取消。结果不明时先查订单,不盲目重复取消;refund_amount 不证明退款已到账。

Input Schema

NameRequiredDescriptionDefault
user_keyYes由可信本地客户端配置的 TourMind 用户凭证;勿让用户在聊天中粘贴。普通 ToC 查询可省略,订单/支付操作必填;OAuth 与 ToB 不接受此字段。
agent_ref_idYescreate_booking 返回的 TourMind 订单号,必须属于当前鉴权用户;不是酒店确认号或第三方支付订单号。

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / agent_ref_id / description
      Previous value: -"TourMind booking reference"New value: +"create_booking 返回的 TourMind 订单号,必须属于当前鉴权用户;不是酒店确认号或第三方支付订单号。"
    • changedInput schema / properties / user_key / description
      Previous value: -"TourMind user key required for authenticated ToC order access"New value: +"由可信本地客户端配置的 TourMind 用户凭证;勿让用户在聊天中粘贴。普通 ToC 查询可省略,订单/支付操作必填;OAuth 与 ToB 不接受此字段。"
    • addedOutput schema / description
      Added value: +"返回字段说明(不增加校验约束;缺失、零值和 null 按各字段说明解释):\n返回值 [object] 必有字段=ok: 业务响应信封;字段缺失表示没有提供,不能自动补零。数组的 null 与 [] 都不含条目,但 null 不承诺完成了该部分查询。\n返回值.data [object] 必有字段=agent_ref_id,status,status_cn,total_amount,cancel_fee,currency,message: 取消处理结果;退款金额不等于退款已到账。\n返回值.data.agent_ref_id [string]: TourMind 订单号。\n返回值.data.cancel_fee [number]: 取消费用,currency 主单位;零表示本次计算无取消费。\n返回值.data.currency [string]: 订单金额币种。\n返回值.data.message [string]: 取消处理和退款说明。\n返回值.data.payment_method [string]: 原支付方式;未发生支付时可能省略。\n返回值.data.refund_amount [number]: 尚需退款金额,currency 主单位;仅特定已付款取消结果返回,缺失不等于零或已到账。\n返回值.data.status [string] 取值=[\"UNPAID\",\"PENDING\",\"CONFIRMED\",\"CANCELLED\",\"CONFIRM_FAILED\"]: 取消处理后的状态:UNPAID=待支付;PENDING=已支付待确认;CONFIRMED=已确认;CANCELLED=已取消;CONFIRM_FAILED=确认失败。仅发起取消不保证状态已变为 CANCELLED。\n返回值.data.status_cn [string]: 取消后订单状态中文说明。\n返回值.data.total_amount [number]: 全部房间、整段入住的订单总价,使用对应币种主单位(如 CNY 元),不是分;未包含另列的 Stripe 手续费,酒店到店收取费用以政策及 exclusions 为准。\n返回值.error [string]: 业务失败说明,不作为可重试或成功的唯一依据。\n返回值.error_code [string]: 鉴权等机器可读错误码,仅在错误路径提供。\n返回值.ok [boolean]: 业务是否成功。false 时读取 error/reason;工具执行错误也可能通过 MCP isError 返回而没有 structuredContent。\n返回值.reason [string] 取值=[\"invalid_request\",\"hotel_not_found\",\"upstream_timeout\",\"upstream_error\",\"hotel_detail_unavailable\"]: 失败原因:invalid_request=参数无效,hotel_not_found=酒店不存在,upstream_timeout=上游超时,upstream_error=上游失败,hotel_detail_unavailable=酒店详情不可用。成功空结果的 no_matching_live_room 位于 data.reason;批量逐项判断,不把一项失败当成整批失败。\n返回值 的分支 1:\n返回值 必有字段=data\n返回值.ok 取值=[true]\n返回值 的分支 2:\n返回值 必有字段=error,reason\n返回值.ok 取值=[false]\n"
  2. Changed1 schema field changed
    • changedInput schema / properties / user_key / description
      Previous value: -"TourMind user key required for authenticated ToC booking operations"New value: +"TourMind user key required for authenticated ToC order access"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds substantive context beyond that: cancellation may incur fees, 'refund_amount does not prove the refund has settled', and repeated cancels should not be attempted on ambiguous outcomes. Credential handling rules (configure via trusted local Skill, never ask users to paste keys in chat) are also disclosed.

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?

The purpose is front-loaded in the first sentence and every later sentence carries real guidance (credentials, pre-cancel verification, retry caution, refund caveat). It is longer than strictly minimal and mixes English and Chinese, which slightly hurts scannability, but nothing is padding.

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?

With destructiveHint annotations covering the safety profile and an output schema covering return values, the description fills the remaining gaps an agent needs for a destructive, credentialed mutation: prerequisite setup, confirmation workflow, retry policy, and refund interpretation.

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 description coverage is 100%, so the baseline is 3; the description nevertheless adds operational meaning for user_key (client-configured credential, never collected in chat, optional for anonymous ToC lookups but mandatory for order/payment actions) and reinforces that agent_ref_id identifies a TourMind order belonging to the authenticated user.

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 (Cancel) and resource (a booking), plus the scope constraint 'owned by the authenticated account'. No sibling performs cancellation, so it is unambiguously distinguishable from query_booking, create_booking and pay_order.

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?

Explicitly prescribes querying the order and obtaining user confirmation of the specific order and possible cancellation fee before cancelling, and states the when-not case: if the result is unclear, re-query instead of blindly retrying. It also names the required prerequisite (a trusted client-supplied user_key) and excludes OAuth/ToB contexts.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.