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

With annotations declaring a non-read-only, non-destructive, non-idempotent, open-world write, the description still adds substantive behavior: this creates a booking request only, does not lock inventory, and involves no payment. It also discloses the authorization prerequisite (guest consent + phone) that the annotations cannot express. What it omits is the post-submission outcome — confirmation, timing, or failure modes — keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The use case is front-loaded in the first clause, followed by mode differentiation and then the preconditions, which matches the order an agent needs them. Density is high with almost no filler, though the single run-on paragraph mixes the store address into flow and could be split for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Across 8 parameters, 3 required and one enum, the description covers purpose, mode choice, consent/phone prerequisites, and the non-ordering nature of the call, which is what an agent needs to invoke it correctly. No output schema exists, so some statement about what a successful submission returns or how the guest is contacted afterward would complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including mode, phone, customer_confirmed, and preferred_time is already documented in the schema; baseline is 3. The description does reinforce mode selection with real-world reasoning (natural light, weighing, certificate over 企业微信 video) and explains why customer_confirmed must be true, but it does not add format or validation detail beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete verb-and-resource framing — '客人想先看实物时用' — and then names the two concrete modes (video inspection by 企业微信 vs. in-store visit at the 浦东 address), including a physical address for the store path. It also rules out the adjacent write operation with '这不是下单，不锁货、不付款', which lets an agent separate this from create_order_intent without inspecting either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It states when to use the tool, how to pick between the two modes (video suits 外地客人, store is the 上海浦东 location and 需预约), and the hard preconditions: customer consent plus a mainland-China 11-digit phone number, with customer_confirmed set to true. It even gives soft guidance ('最好问一下方便的时间，填进 preferred_time'), so both the trigger and the required sequence are explicit.

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